Re: [PATCH v6 03/24] iio: make use of devm_iio_kfifo_buffer_setup() helper
On Tue, Feb 16, 2021 at 3:46 PM Gwendal Grignou wrote: > > Reviewed-by: Gwendal Grignou Looks fine to me as well. Reviewed-by: Matt Ranostay > > On Mon, Feb 15, 2021 at 4:11 AM Jonathan Cameron wrote: > > > > On Mon, 15 Feb 2021 12:40:22 +0200 > > Alexandru Ardelean wrote: > > > > > All drivers that already call devm_iio_kfifo_allocate() & > > > iio_device_attach_buffer() are simple to convert to > > > iio_device_attach_kfifo_buffer() in a single go. > > > > > > This change does that; the unwind order is preserved. > > > What is important, is that the devm_iio_kfifo_buffer_setup() be called > > > after the indio_dev->modes is assigned, to make sure that > > > INDIO_BUFFER_SOFTWARE flag is set and not overridden by the assignment to > > > indio_dev->modes. > > > > > > Also, the INDIO_BUFFER_SOFTWARE has been removed from the assignments of > > > 'indio_dev->modes' because it is set by devm_iio_kfifo_buffer_setup(). > > > > > > Signed-off-by: Alexandru Ardelean > > I 'think' this one is is in the obviously correct category so I've > > applied it to the togreg branch of iio.git and pushed out as testing. > > Note there is still plenty of time for any additional feedback, > > particularly as the CC list was a little sparse. > > > > I've +CCd those who I know are still active maintainers of some > > of the affected drivers. > > > > Jonathan > > > > > --- > > > drivers/iio/accel/ssp_accel_sensor.c | 14 --- > > > drivers/iio/adc/ina2xx-adc.c | 14 +-- > > > drivers/iio/adc/ti_am335x_adc.c | 18 --- > > > .../cros_ec_sensors/cros_ec_sensors_core.c| 13 --- > > > drivers/iio/gyro/ssp_gyro_sensor.c| 14 --- > > > drivers/iio/health/max30100.c | 16 ++--- > > > drivers/iio/health/max30102.c | 16 ++--- > > > .../iio/imu/inv_icm42600/inv_icm42600_accel.c | 14 +-- > > > .../iio/imu/inv_icm42600/inv_icm42600_gyro.c | 13 +-- > > > .../iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c| 15 +--- > > > drivers/iio/light/acpi-als.c | 12 -- > > > drivers/iio/light/apds9960.c | 16 ++--- > > > .../staging/iio/impedance-analyzer/ad5933.c | 23 --- > > > 13 files changed, 74 insertions(+), 124 deletions(-) > > > > > > diff --git a/drivers/iio/accel/ssp_accel_sensor.c > > > b/drivers/iio/accel/ssp_accel_sensor.c > > > index 474477e91b5e..04dcb2b657ee 100644 > > > --- a/drivers/iio/accel/ssp_accel_sensor.c > > > +++ b/drivers/iio/accel/ssp_accel_sensor.c > > > @@ -96,7 +96,6 @@ static int ssp_accel_probe(struct platform_device *pdev) > > > int ret; > > > struct iio_dev *indio_dev; > > > struct ssp_sensor_data *spd; > > > - struct iio_buffer *buffer; > > > > > > indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*spd)); > > > if (!indio_dev) > > > @@ -109,18 +108,15 @@ static int ssp_accel_probe(struct platform_device > > > *pdev) > > > > > > indio_dev->name = ssp_accel_device_name; > > > indio_dev->info = &ssp_accel_iio_info; > > > - indio_dev->modes = INDIO_BUFFER_SOFTWARE; > > > indio_dev->channels = ssp_acc_channels; > > > indio_dev->num_channels = ARRAY_SIZE(ssp_acc_channels); > > > indio_dev->available_scan_masks = ssp_accel_scan_mask; > > > > > > - buffer = devm_iio_kfifo_allocate(&pdev->dev); > > > - if (!buffer) > > > - return -ENOMEM; > > > - > > > - iio_device_attach_buffer(indio_dev, buffer); > > > - > > > - indio_dev->setup_ops = &ssp_accel_buffer_ops; > > > + ret = devm_iio_kfifo_buffer_setup(&pdev->dev, indio_dev, > > > + INDIO_BUFFER_SOFTWARE, > > > + &ssp_accel_buffer_ops); > > > + if (ret) > > > + return ret; > > > > > > platform_set_drvdata(pdev, indio_dev); > > > > > > diff --git a/drivers/iio/adc/ina2xx-adc.c b/drivers/iio/adc/ina2xx-adc.c > > > index b573ec60a8b8..2ae54258b221 100644 > > > --- a/drivers/iio/adc/ina2xx-adc.c > > >
Re: [PATCH] iio:light:apds9960 add detection for MSHW0184 ACPI device in apds9960 driver
On Sat, Dec 19, 2020 at 5:51 PM Max Leiter wrote:
>
> The device is used in the Microsoft Surface Book 3 and Surface Pro 7
>
> Signed-off-by: Max Leiter
Reviewed-by: Matt Ranostay
> ---
> drivers/iio/light/apds9960.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/iio/light/apds9960.c b/drivers/iio/light/apds9960.c
> index 9afb3fcc74e6..20719141c03a 100644
> --- a/drivers/iio/light/apds9960.c
> +++ b/drivers/iio/light/apds9960.c
> @@ -8,6 +8,7 @@
> * TODO: gesture + proximity calib offsets
> */
>
> +#include
> #include
> #include
> #include
> @@ -1113,6 +1114,12 @@ static const struct i2c_device_id apds9960_id[] = {
> };
> MODULE_DEVICE_TABLE(i2c, apds9960_id);
>
> +static const struct acpi_device_id apds9960_acpi_match[] = {
> + { "MSHW0184" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, apds9960_acpi_match);
> +
> static const struct of_device_id apds9960_of_match[] = {
> { .compatible = "avago,apds9960" },
> { }
> @@ -1124,6 +1131,7 @@ static struct i2c_driver apds9960_driver = {
> .name = APDS9960_DRV_NAME,
> .of_match_table = apds9960_of_match,
> .pm = &apds9960_pm_ops,
> + .acpi_match_table = apds9960_acpi_match,
> },
> .probe = apds9960_probe,
> .remove = apds9960_remove,
> --
> 2.29.2
>
Re: [PATCH] iio: light: apds9960: remove unneeded semicolon
On Tue, Oct 27, 2020 at 1:14 PM wrote: > > From: Tom Rix > > A semicolon is not needed after a switch statement. > Acked-by: Matt Ranostay > Signed-off-by: Tom Rix > --- > drivers/iio/light/apds9960.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/iio/light/apds9960.c b/drivers/iio/light/apds9960.c > index 9afb3fcc74e6..547e7f9d6920 100644 > --- a/drivers/iio/light/apds9960.c > +++ b/drivers/iio/light/apds9960.c > @@ -561,7 +561,7 @@ static int apds9960_write_raw(struct iio_dev *indio_dev, > } > default: > return -EINVAL; > - }; > + } > > return 0; > } > -- > 2.18.1 >
Re: [PATCH] iio: proximity: as3935 change of_property_read to device_property_read
On Fri, Oct 16, 2020 at 11:41 AM Vaishnav M A wrote:
>
>
> This patch aims to replace the of_property_read_u32 for reading
> the ams,tuning-capacitor-pf, ams,nflwdth properties with
> device_property_read_u32.
>
> Thanks and Regards,
> Vaishnav M A
Could you explain a bit more in the commit message why this is needed?
Also you pop comments that shouldn't be in the commit message below
the "---" line :)
>
> Signed-off-by: Vaishnav M A
> ---
> drivers/iio/proximity/as3935.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/proximity/as3935.c b/drivers/iio/proximity/as3935.c
> index c339e7339ec8..7e47ddf89a56 100644
> --- a/drivers/iio/proximity/as3935.c
> +++ b/drivers/iio/proximity/as3935.c
> @@ -355,7 +355,6 @@ static int as3935_probe(struct spi_device *spi)
> struct iio_dev *indio_dev;
> struct iio_trigger *trig;
> struct as3935_state *st;
> - struct device_node *np = spi->dev.of_node;
> int ret;
>
> /* Be sure lightning event interrupt is specified */
> @@ -374,7 +373,7 @@ static int as3935_probe(struct spi_device *spi)
> spi_set_drvdata(spi, indio_dev);
> mutex_init(&st->lock);
>
> - ret = of_property_read_u32(np,
> + ret = device_property_read_u32(&spi->dev,
> "ams,tuning-capacitor-pf", &st->tune_cap);
> if (ret) {
> st->tune_cap = 0;
> @@ -390,7 +389,7 @@ static int as3935_probe(struct spi_device *spi)
> return -EINVAL;
> }
>
> - ret = of_property_read_u32(np,
> + ret = device_property_read_u32(&spi->dev,
> "ams,nflwdth", &st->nflwdth_reg);
> if (!ret && st->nflwdth_reg > AS3935_NFLWDTH_MASK) {
> dev_err(&spi->dev,
> --
> 2.25.1
>
Re: [PATCH 5.4 047/215] iio:humidity:hdc100x Fix alignment and data leak issues
On Mon, Jul 20, 2020 at 9:50 AM Joe Perches wrote:
>
> On Mon, 2020-07-20 at 17:35 +0200, Greg Kroah-Hartman wrote:
> > From: Jonathan Cameron
> >
> > commit ea5e7a7bb6205d24371373cd80325db1bc15eded upstream.
> >
> > One of a class of bugs pointed out by Lars in a recent review.
> > iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
> > to the size of the timestamp (8 bytes). This is not guaranteed in
> > this driver which uses an array of smaller elements on the stack.
> > As Lars also noted this anti pattern can involve a leak of data to
> > userspace and that indeed can happen here. We close both issues by
> > moving to a suitable structure in the iio_priv() data.
> > This data is allocated with kzalloc so no data can leak apart
> > from previous readings.
> []
> > +++ b/drivers/iio/humidity/hdc100x.c
> > @@ -38,6 +38,11 @@ struct hdc100x_data {
> >
> > /* integration time of the sensor */
> > int adc_int_us[2];
> > + /* Ensure natural alignment of timestamp */
> > + struct {
> > + __be16 channels[2];
> > + s64 ts __aligned(8);
>
> Why does an s64 need __aligned(8) ?
This is due to on 32-bit x86 it is aligned to 4 bytes by default.
- Matt
> This seems needlessly redundant.
>
> Isn't this naturally aligned by the compiler?
>
> The struct isn't packed.
>
Re: [PATCH v2] Replace HTTP links with HTTPS ones: Documentation/devicetree/bindings/iio
On Sat, Jul 4, 2020 at 12:34 PM Alexander A. Klimov wrote: > > Rationale: > Reduces attack surface on kernel devs opening the links for MITM > as HTTPS traffic is much harder to manipulate. > With regards to the drivers that I've authored the changes look good to me. Reviewed-by: Matt Ranostay > Deterministic algorithm: > For each file: > If not .svg: > For each line: > If doesn't contain `\bxmlns\b`: > For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: > If both the HTTP and HTTPS versions > return 200 OK and serve the same content: > Replace HTTP with HTTPS. > > Signed-off-by: Alexander A. Klimov > --- > Changes in v2: > Addressed > https://lore.kernel.org/linux-iio/20200704173459.78ceec60@archlinux/ > > Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml | 4 ++-- > Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt | 2 +- > Documentation/devicetree/bindings/iio/iio-bindings.txt| 2 +- > Documentation/devicetree/bindings/iio/light/apds9300.txt | 2 +- > Documentation/devicetree/bindings/iio/light/apds9960.txt | 2 +- > Documentation/devicetree/bindings/iio/light/opt3001.txt | 2 +- > Documentation/devicetree/bindings/iio/light/vl6180.txt| 2 +- > .../devicetree/bindings/iio/potentiometer/mcp41010.txt| 2 +- > .../devicetree/bindings/iio/potentiostat/lmp91000.txt | 4 ++-- > .../devicetree/bindings/iio/pressure/asc,dlhl60d.yaml | 2 +- > .../devicetree/bindings/iio/proximity/devantech-srf04.yaml| 4 ++-- > 11 files changed, 14 insertions(+), 14 deletions(-) > > diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml > b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml > index d124eba1ce54..fd4eaa3d0ab4 100644 > --- a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml > +++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml > @@ -12,8 +12,8 @@ maintainers: > description: | >Analog Devices ADXL345/ADXL375 3-Axis Digital Accelerometers that supports >both I2C & SPI interfaces. > -http://www.analog.com/en/products/mems/accelerometers/adxl345.html > - > http://www.analog.com/en/products/sensors-mems/accelerometers/adxl375.html > +https://www.analog.com/en/products/mems/accelerometers/adxl345.html > + > https://www.analog.com/en/products/sensors-mems/accelerometers/adxl375.html > > properties: >compatible: > diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt > b/Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt > index 639c94ed83e9..17af395b99d9 100644 > --- a/Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt > +++ b/Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt > @@ -6,7 +6,7 @@ Is is programmable through an SPI interface. > > The internal DACs are loaded when the LOADDACS pin is pulled down. > > -http://www.ti.com/lit/ds/sbas106/sbas106.pdf > +https://www.ti.com/lit/ds/sbas106/sbas106.pdf > > Required Properties: > - compatible: Should be one of: > diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt > b/Documentation/devicetree/bindings/iio/iio-bindings.txt > index af33267727f4..aa63cac7323e 100644 > --- a/Documentation/devicetree/bindings/iio/iio-bindings.txt > +++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt > @@ -9,7 +9,7 @@ specifier is an array of one or more cells identifying the IIO > output on a device. The length of an IIO specifier is defined by the > value of a #io-channel-cells property in the IIO provider node. > > -[1] http://marc.info/?l=linux-iio&m=135902119507483&w=2 > +[1] https://marc.info/?l=linux-iio&m=135902119507483&w=2 > > ==IIO providers== > > diff --git a/Documentation/devicetree/bindings/iio/light/apds9300.txt > b/Documentation/devicetree/bindings/iio/light/apds9300.txt > index aa199e09a493..3aa6db3ee99d 100644 > --- a/Documentation/devicetree/bindings/iio/light/apds9300.txt > +++ b/Documentation/devicetree/bindings/iio/light/apds9300.txt > @@ -1,6 +1,6 @@ > * Avago APDS9300 ambient light sensor > > -http://www.avagotech.com/docs/AV02-1077EN > +https://www.avagotech.com/docs/AV02-1077EN > > Required properties: > > diff --git a/Documentation/devicetree/bindings/iio/light/apds9960.txt > b/Documentation/devicetree/bindings/iio/light/apds9960.txt > index 3af325ad194b..c53ddb81c4aa 100644 > --- a/Documentation/devicetree/bindings/iio/light/apds9960.txt > +++ b/Documentation/devicetree/bindings/iio/light/apds9960.txt > @@ -1,6 +1,6 @@ > * Avago APDS9960 gesture/RGB/ALS/proximity sensor > > -http://www.avagotech.com/docs/AV02-4191EN > +https://www
Re: [PATCH] iio: improve IIO_CONCENTRATION channel type description
On Mon, Jun 1, 2020 at 9:18 AM Tomasz Duszynski
wrote:
>
> IIO_CONCENTRATION together with INFO_RAW specifier is used for reporting
> raw concentrations of pollutants. Raw value should be meaningless
> before being properly scaled. Because of that description shouldn't
> mention raw value unit whatsoever.
>
> Fix this by rephrasing existing description so it follows conventions
> used throughout IIO ABI docs.
Acked-by: Matt Ranostay
>
> Fixes: 8ff6b3bc94930 ("iio: chemical: Add IIO_CONCENTRATION channel type")
> Signed-off-by: Tomasz Duszynski
> ---
> Documentation/ABI/testing/sysfs-bus-iio | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> b/Documentation/ABI/testing/sysfs-bus-iio
> index d3e53a6d8331..5c62bfb0f3f5 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -1569,7 +1569,8 @@ What:
> /sys/bus/iio/devices/iio:deviceX/in_concentrationX_voc_raw
> KernelVersion: 4.3
> Contact: linux-...@vger.kernel.org
> Description:
> - Raw (unscaled no offset etc.) percentage reading of a
> substance.
> + Raw (unscaled no offset etc.) reading of a substance. Units
> + after application of scale and offset are percents.
>
> What: /sys/bus/iio/devices/iio:deviceX/in_resistance_raw
> What: /sys/bus/iio/devices/iio:deviceX/in_resistanceX_raw
> --
> 2.26.2
>
Re: [PATCH v2 2/3] iio: dps310: Temperature measurement errata
On Thu, May 9, 2019 at 11:17 PM Eddie James wrote:
>
>
> On 5/8/19 10:09 PM, Matt Ranostay wrote:
> > On Thu, May 9, 2019 at 3:36 AM Eddie James wrote:
> >> From: Christopher Bostic
> >>
> >> Add a manufacturer's suggested workaround to deal with early revisions
> >> of chip that don't indicate correct temperature. Readings can be in the
> >> ~60C range when they should be in the ~20's.
> >>
> >> Signed-off-by: Christopher Bostic
> >> Signed-off-by: Joel Stanley
> >> Signed-off-by: Eddie James
> >> ---
> >> drivers/iio/pressure/dps310.c | 51
> >> ++-
> >> 1 file changed, 50 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/iio/pressure/dps310.c b/drivers/iio/pressure/dps310.c
> >> index 7afaa88..c42808e 100644
> >> --- a/drivers/iio/pressure/dps310.c
> >> +++ b/drivers/iio/pressure/dps310.c
> >> @@ -221,6 +221,9 @@ static bool dps310_is_writeable_reg(struct device
> >> *dev, unsigned int reg)
> >> case DPS310_MEAS_CFG:
> >> case DPS310_CFG_REG:
> >> case DPS310_RESET:
> >> + case 0x0e:
> >> + case 0x0f:
> >> + case 0x62:
> > What is with the magic values? Are they not documented to what they
> > are, and hence not defining enum values for them?
> >
> > - Matt
>
>
> Thats correct. These don't show up in the data sheet so I left them as
> raw values. Chris, do you know what the source for these values was?
Please at least make a comment in the code stating as much.
- Matt
>
> Thanks,
>
> Eddie
>
>
> >
> >> return true;
> >> default:
> >> return false;
> >> @@ -237,6 +240,7 @@ static bool dps310_is_volatile_reg(struct device *dev,
> >> unsigned int reg)
> >> case DPS310_TMP_B1:
> >> case DPS310_TMP_B2:
> >> case DPS310_MEAS_CFG:
> >> + case 0x32:
> >> return true;
> >> default:
> >> return false;
> >> @@ -314,7 +318,7 @@ static int dps310_read_raw(struct iio_dev *iio,
> >> .writeable_reg = dps310_is_writeable_reg,
> >> .volatile_reg = dps310_is_volatile_reg,
> >> .cache_type = REGCACHE_RBTREE,
> >> - .max_register = 0x29,
> >> + .max_register = 0x62,
> >> };
> >>
> >> static const struct iio_info dps310_info = {
> >> @@ -322,6 +326,47 @@ static int dps310_read_raw(struct iio_dev *iio,
> >> .write_raw = dps310_write_raw,
> >> };
> >>
> >> +/*
> >> + * Some verions of chip will read temperatures in the ~60C range when
> >> + * its actually ~20C. This is the manufacturer recommended workaround
> >> + * to correct the issue.
> >> + */
> >> +static int dps310_temp_workaround(struct dps310_data *data)
> >> +{
> >> + int r, reg;
> >> +
> >> + r = regmap_read(data->regmap, 0x32, ®);
> >> + if (r < 0)
> >> + return r;
> >> +
> >> + /*
> >> +* If bit 1 is set then the device is okay, and the workaround
> >> does not
> >> +* need to be applied
> >> +*/
> >> + if (reg & BIT(1))
> >> + return 0;
> >> +
> >> + r = regmap_write(data->regmap, 0x0e, 0xA5);
> >> + if (r < 0)
> >> + return r;
> >> +
> >> + r = regmap_write(data->regmap, 0x0f, 0x96);
> >> + if (r < 0)
> >> + return r;
> >> +
> >> + r = regmap_write(data->regmap, 0x62, 0x02);
> >> + if (r < 0)
> >> + return r;
> >> +
> >> + r = regmap_write(data->regmap, 0x0e, 0x00);
> >> + if (r < 0)
> >> + return r;
> >> +
> >> + r = regmap_write(data->regmap, 0x0f, 0x00);
> >> +
> >> + return r;
> >> +}
> >> +
> >> static int dps310_probe(struct i2c_client *client,
> >> const struct i2c_device_id *id)
> >> {
> >> @@ -383,6 +428,10 @@ static int dps310_probe(struct i2c_client *client,
> >> if (r < 0)
> >> goto err;
> >>
> >> + r = dps310_temp_workaround(data);
> >> + if (r < 0)
> >> + return r;
> >> +
> >> r = devm_iio_device_register(&client->dev, iio);
> >> if (r)
> >> goto err;
> >> --
> >> 1.8.3.1
> >>
>
Re: [PATCH v2 2/3] iio: dps310: Temperature measurement errata
On Thu, May 9, 2019 at 3:36 AM Eddie James wrote:
>
> From: Christopher Bostic
>
> Add a manufacturer's suggested workaround to deal with early revisions
> of chip that don't indicate correct temperature. Readings can be in the
> ~60C range when they should be in the ~20's.
>
> Signed-off-by: Christopher Bostic
> Signed-off-by: Joel Stanley
> Signed-off-by: Eddie James
> ---
> drivers/iio/pressure/dps310.c | 51
> ++-
> 1 file changed, 50 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/pressure/dps310.c b/drivers/iio/pressure/dps310.c
> index 7afaa88..c42808e 100644
> --- a/drivers/iio/pressure/dps310.c
> +++ b/drivers/iio/pressure/dps310.c
> @@ -221,6 +221,9 @@ static bool dps310_is_writeable_reg(struct device *dev,
> unsigned int reg)
> case DPS310_MEAS_CFG:
> case DPS310_CFG_REG:
> case DPS310_RESET:
> + case 0x0e:
> + case 0x0f:
> + case 0x62:
What is with the magic values? Are they not documented to what they
are, and hence not defining enum values for them?
- Matt
> return true;
> default:
> return false;
> @@ -237,6 +240,7 @@ static bool dps310_is_volatile_reg(struct device *dev,
> unsigned int reg)
> case DPS310_TMP_B1:
> case DPS310_TMP_B2:
> case DPS310_MEAS_CFG:
> + case 0x32:
> return true;
> default:
> return false;
> @@ -314,7 +318,7 @@ static int dps310_read_raw(struct iio_dev *iio,
> .writeable_reg = dps310_is_writeable_reg,
> .volatile_reg = dps310_is_volatile_reg,
> .cache_type = REGCACHE_RBTREE,
> - .max_register = 0x29,
> + .max_register = 0x62,
> };
>
> static const struct iio_info dps310_info = {
> @@ -322,6 +326,47 @@ static int dps310_read_raw(struct iio_dev *iio,
> .write_raw = dps310_write_raw,
> };
>
> +/*
> + * Some verions of chip will read temperatures in the ~60C range when
> + * its actually ~20C. This is the manufacturer recommended workaround
> + * to correct the issue.
> + */
> +static int dps310_temp_workaround(struct dps310_data *data)
> +{
> + int r, reg;
> +
> + r = regmap_read(data->regmap, 0x32, ®);
> + if (r < 0)
> + return r;
> +
> + /*
> +* If bit 1 is set then the device is okay, and the workaround does
> not
> +* need to be applied
> +*/
> + if (reg & BIT(1))
> + return 0;
> +
> + r = regmap_write(data->regmap, 0x0e, 0xA5);
> + if (r < 0)
> + return r;
> +
> + r = regmap_write(data->regmap, 0x0f, 0x96);
> + if (r < 0)
> + return r;
> +
> + r = regmap_write(data->regmap, 0x62, 0x02);
> + if (r < 0)
> + return r;
> +
> + r = regmap_write(data->regmap, 0x0e, 0x00);
> + if (r < 0)
> + return r;
> +
> + r = regmap_write(data->regmap, 0x0f, 0x00);
> +
> + return r;
> +}
> +
> static int dps310_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> @@ -383,6 +428,10 @@ static int dps310_probe(struct i2c_client *client,
> if (r < 0)
> goto err;
>
> + r = dps310_temp_workaround(data);
> + if (r < 0)
> + return r;
> +
> r = devm_iio_device_register(&client->dev, iio);
> if (r)
> goto err;
> --
> 1.8.3.1
>
Re: [PATCH v2] iio: temperature: maxim_thermocouple: declare missing of table
On Wed, Apr 24, 2019 at 5:42 AM Daniel Gomez wrote:
>
> Add missing table for SPI driver relying on SPI
> device match since compatible is in a DT binding or in a DTS.
>
> Before this patch:
> modinfo drivers/iio/temperature/maxim_thermocouple.ko | grep alias
> alias: spi:max31855
> alias: spi:max6675
>
> After this patch:
> modinfo drivers/iio/temperature/maxim_thermocouple.ko | grep alias
> alias: spi:max31855
> alias: spi:max6675
> alias: of:N*T*Cmaxim,max31855C*
> alias: of:N*T*Cmaxim,max31855
> alias: of:N*T*Cmaxim,max6675C*
> alias: of:N*T*Cmaxim,max6675
Heh oops I missed that somehow in initial development.
Acked-by: Matt Ranostay
>
> Reported-by: Javier Martinez Canillas
> Signed-off-by: Daniel Gomez
> ---
> drivers/iio/temperature/maxim_thermocouple.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/iio/temperature/maxim_thermocouple.c
> b/drivers/iio/temperature/maxim_thermocouple.c
> index c31b963..c613a64 100644
> --- a/drivers/iio/temperature/maxim_thermocouple.c
> +++ b/drivers/iio/temperature/maxim_thermocouple.c
> @@ -10,6 +10,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -262,9 +264,17 @@ static const struct spi_device_id
> maxim_thermocouple_id[] = {
> };
> MODULE_DEVICE_TABLE(spi, maxim_thermocouple_id);
>
> +static const struct of_device_id maxim_thermocouple_of_match[] = {
> +{ .compatible = "maxim,max6675" },
> +{ .compatible = "maxim,max31855" },
> +{ },
> +};
> +MODULE_DEVICE_TABLE(of, maxim_thermocouple_of_match);
> +
> static struct spi_driver maxim_thermocouple_driver = {
> .driver = {
> .name = MAXIM_THERMOCOUPLE_DRV_NAME,
> + .of_match_table = maxim_thermocouple_of_match,
> },
> .probe = maxim_thermocouple_probe,
> .remove = maxim_thermocouple_remove,
> --
> 2.7.4
>
Re: [PATCH] drivers: iio: proximity: This patch fix the following checkpatch warning.
On Mon, Apr 22, 2019 at 6:48 PM Jonathan Cameron wrote:
>
> On Thu, 18 Apr 2019 16:23:51 -0700
> Matt Ranostay wrote:
>
> > See comments inline
> >
> > On Wed, Apr 17, 2019 at 11:15 AM Mohan Kumar
> > wrote:
> > >
> > > As per Documentation/timers/timers-howto.txt Msleep < 20ms can sleep for
> > > up to 20ms. so use usleep_range.
> > >
> > > Signed-off-by: Mohan Kumar
> > > ---
> > > drivers/iio/proximity/mb1232.c | 2 +-
> > > drivers/iio/proximity/srf08.c | 4 ++--
> > > 2 files changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/iio/proximity/mb1232.c
> > > b/drivers/iio/proximity/mb1232.c
> > > index 166b3e6..74f7eae 100644
> > > --- a/drivers/iio/proximity/mb1232.c
> > > +++ b/drivers/iio/proximity/mb1232.c
> > > @@ -81,7 +81,7 @@ static s16 mb1232_read_distance(struct mb1232_data
> > > *data)
> > > }
> > > } else {
> > > /* use simple sleep if announce irq is not connected */
> > > - msleep(15);
> > > + usleep_range(15000, 2);
> >
> > This is actually less than ideal.. because usleep_range uses the
> > hrtimers which forces an interrupt.
> >
> > Unless you actually need to read between 15ms and 20ms it is best just
> > to leave the msleep() as it is, and let it take a bit longer
> > if required.
> Good response. Perhaps Mohan could follow up with a patch to add
> a comment to this effect to save anyone else trying to 'fix' this
> issue in future?
Change of the warning message in the checkpatch.pl script you mean?
- Matt
>
> Thanks,
>
> Jonathan
> >
> > - Matt
> >
> > > }
> > >
> > > ret = i2c_master_recv(client, (char *)&buf, sizeof(buf));
> > > diff --git a/drivers/iio/proximity/srf08.c b/drivers/iio/proximity/srf08.c
> > > index f2bf783..605a582 100644
> > > --- a/drivers/iio/proximity/srf08.c
> > > +++ b/drivers/iio/proximity/srf08.c
> > > @@ -150,7 +150,7 @@ static int srf08_read_ranging(struct srf08_data *data)
> > > * polling for not more than 20 ms should be enough
> > > */
> > > waittime = 1 + data->range_mm / 172;
> > > - msleep(waittime);
> > > + usleep_range(waittime * 1000, (waittime * 1000) + 2000);
> > > for (i = 0; i < 4; i++) {
> > > ret = i2c_smbus_read_byte_data(data->client,
> > > SRF08_READ_SW_REVISION);
> > > @@ -158,7 +158,7 @@ static int srf08_read_ranging(struct srf08_data *data)
> > > /* check if a valid version number is read */
> > > if (ret < 255 && ret > 0)
> > > break;
> > > - msleep(5);
> > > + usleep_range(5000, 15000);
> > > }
> > >
> > > if (ret >= 255 || ret <= 0) {
> > > --
> > > 2.7.4
> > >
>
Re: [PATCH] drivers: iio: proximity: This patch fix the following checkpatch warning.
See comments inline
On Wed, Apr 17, 2019 at 11:15 AM Mohan Kumar wrote:
>
> As per Documentation/timers/timers-howto.txt Msleep < 20ms can sleep for
> up to 20ms. so use usleep_range.
>
> Signed-off-by: Mohan Kumar
> ---
> drivers/iio/proximity/mb1232.c | 2 +-
> drivers/iio/proximity/srf08.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/proximity/mb1232.c b/drivers/iio/proximity/mb1232.c
> index 166b3e6..74f7eae 100644
> --- a/drivers/iio/proximity/mb1232.c
> +++ b/drivers/iio/proximity/mb1232.c
> @@ -81,7 +81,7 @@ static s16 mb1232_read_distance(struct mb1232_data *data)
> }
> } else {
> /* use simple sleep if announce irq is not connected */
> - msleep(15);
> + usleep_range(15000, 2);
This is actually less than ideal.. because usleep_range uses the
hrtimers which forces an interrupt.
Unless you actually need to read between 15ms and 20ms it is best just
to leave the msleep() as it is, and let it take a bit longer
if required.
- Matt
> }
>
> ret = i2c_master_recv(client, (char *)&buf, sizeof(buf));
> diff --git a/drivers/iio/proximity/srf08.c b/drivers/iio/proximity/srf08.c
> index f2bf783..605a582 100644
> --- a/drivers/iio/proximity/srf08.c
> +++ b/drivers/iio/proximity/srf08.c
> @@ -150,7 +150,7 @@ static int srf08_read_ranging(struct srf08_data *data)
> * polling for not more than 20 ms should be enough
> */
> waittime = 1 + data->range_mm / 172;
> - msleep(waittime);
> + usleep_range(waittime * 1000, (waittime * 1000) + 2000);
> for (i = 0; i < 4; i++) {
> ret = i2c_smbus_read_byte_data(data->client,
> SRF08_READ_SW_REVISION);
> @@ -158,7 +158,7 @@ static int srf08_read_ranging(struct srf08_data *data)
> /* check if a valid version number is read */
> if (ret < 255 && ret > 0)
> break;
> - msleep(5);
> + usleep_range(5000, 15000);
> }
>
> if (ret >= 255 || ret <= 0) {
> --
> 2.7.4
>
Re: [PATCH 0/5] *** SUBJECT HERE ***
You may want to change "*** SUBJECT HERE ***" in the future :) - Matt On Sat, Mar 23, 2019 at 5:53 AM Cristian Sicilia wrote: > > Some source refactoring, parameters aligment and camel case clearing. > > Replacement of bool to bitfield in a struct, but not found > the population to check if it is done correctly. > > Cristian Sicilia (5): > staging: iio: adc: Tab alignment > staging: iio: adc: Converted bool to bitfield format > staging: iio: adc: Avoid precedence issues in macro > staging: iio: adc: Adding temp var to improve readability > staging: iio: adc: Remove CamelCase notation > > drivers/staging/iio/adc/ad7192.h | 16 +++--- > drivers/staging/iio/adc/ad7280a.c | 109 > ++ > 2 files changed, 60 insertions(+), 65 deletions(-) > > -- > 2.7.4 >
Re: [PATCH] Staging: iio: ad7192: replaced bool in struct
> On Dec 24, 2018, at 01:58, Himanshu Jha wrote:
>
>> On Fri, Dec 21, 2018 at 03:26:26PM -0800, Amir Mahdi Ghorbanian wrote:
>> Replaced bool in struct with unsigned int bitfield to conserve space and
>> more clearly define size of varibales
Important thing to note is depending on padding, alignment, and position of
field it probably won’t save any space.
Also for internal unpacked structures it really makes little sense to save a
few bytes of data. Don’t read into that packed structures are good.. they
usually aren’t :)
- Matt
>>
>> Signed-off-by: Amir Mahdi Ghorbanian
>> ---
>
> There was some discussion on this at Outreachy list:
> https://groups.google.com/d/msg/outreachy-kernel/xpQAl-Gn8HA/yqcQRG_qBgAJ
>
> I think unless you post some statistics about 'conserving' space,
> it is unlikely that maintainers will apply it.
>
> This idea was originally given by Linus and that thread of discussion
> is worth reading too.
>
>> drivers/staging/iio/adc/ad7192.h | 14 +++---
>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/staging/iio/adc/ad7192.h
>> b/drivers/staging/iio/adc/ad7192.h
>> index 7433a43..7d3e62f 100644
>> --- a/drivers/staging/iio/adc/ad7192.h
>> +++ b/drivers/staging/iio/adc/ad7192.h
>> @@ -35,13 +35,13 @@ struct ad7192_platform_data {
>>u16vref_mv;
>>u8clock_source_sel;
>>u32ext_clk_hz;
>> -boolrefin2_en;
>> -boolrej60_en;
>> -boolsinc3_en;
>> -boolchop_en;
>> -boolbuf_en;
>> -boolunipolar_en;
>> -boolburnout_curr_en;
>> +unsigned intrefin2_en : 1;
>> +unsigned intrej60_en : 1;
>> +unsigned intsinc3_en : 1;
>> +unsigned intchop_en : 1;
>> +unsigned intbuf_en : 1;
>> +unsigned intunipolar_en : 1;
>> +unsigned intburnout_curr_en : 1;
>> };
>>
>> #endif /* IIO_ADC_AD7192_H_ */
>> --
>> 2.7.4
>>
>
> Goodluck!
>
> --
> Himanshu Jha
> Undergraduate Student
> Department of Electronics & Communication
> Guru Tegh Bahadur Institute of Technology
Re: [PATCH v3 1/3] iio: add IIO_MASSCONCENTRATION channel type
On Wed, Dec 12, 2018 at 10:31 AM Tomasz Duszynski wrote:
>
> Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> is de facto standard. Existing air quality sensors usually follow
> this convention and are capable of returning measurements using
> this unit.
>
> IIO currently does not offer suitable channel type for this
> type of measurements hence this patch adds this.
>
> In addition, extra modifiers are introduced used for distinguishing
> between fine pm1, pm2p5 and coarse pm4, pm10 particle measurements, i.e
> IIO_MOD_PM1, IIO_MOD_PM25 and IIO_MOD_PM4, IIO_MOD_PM10.
>
> pmX consists of particles with aerodynamic diameter less or equal to
> X micrometers.
>
Acked-by: Matt Ranostay
> Signed-off-by: Tomasz Duszynski
> ---
> Documentation/ABI/testing/sysfs-bus-iio | 17 -
> drivers/iio/industrialio-core.c | 5 +
> include/uapi/linux/iio/types.h | 5 +
> tools/iio/iio_event_monitor.c | 10 ++
> 4 files changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> b/Documentation/ABI/testing/sysfs-bus-iio
> index 8127a08e366d..ad9579a9385f 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -1684,4 +1684,19 @@ KernelVersion: 4.18
> Contact: linux-...@vger.kernel.org
> Description:
> Raw (unscaled) phase difference reading from channel Y
> - that can be processed to radians.
> \ No newline at end of file
> + that can be processed to radians.
> +
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm1_input
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm1_input
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm4_input
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm4_input
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> +KernelVersion: 4.21
> +Contact: linux-...@vger.kernel.org
> +Description:
> + Mass concentration reading of particulate matter in ug / m3.
> + pmX consists of particles with aerodynamic diameter less or
> + equal to X micrometers.
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 4f5cd9f60870..4700fd5d8c90 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_GRAVITY] = "gravity",
> [IIO_POSITIONRELATIVE] = "positionrelative",
> [IIO_PHASE] = "phase",
> + [IIO_MASSCONCENTRATION] = "massconcentration",
> };
>
> static const char * const iio_modifier_names[] = {
> @@ -127,6 +128,10 @@ static const char * const iio_modifier_names[] = {
> [IIO_MOD_Q] = "q",
> [IIO_MOD_CO2] = "co2",
> [IIO_MOD_VOC] = "voc",
> + [IIO_MOD_PM1] = "pm1",
> + [IIO_MOD_PM2P5] = "pm2p5",
> + [IIO_MOD_PM4] = "pm4",
> + [IIO_MOD_PM10] = "pm10",
> };
>
> /* relies on pairs of these shared then separate */
> diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> index 92baabc103ac..c59adac24b1c 100644
> --- a/include/uapi/linux/iio/types.h
> +++ b/include/uapi/linux/iio/types.h
> @@ -46,6 +46,7 @@ enum iio_chan_type {
> IIO_GRAVITY,
> IIO_POSITIONRELATIVE,
> IIO_PHASE,
> + IIO_MASSCONCENTRATION,
> };
>
> enum iio_modifier {
> @@ -87,6 +88,10 @@ enum iio_modifier {
> IIO_MOD_VOC,
> IIO_MOD_LIGHT_UV,
> IIO_MOD_LIGHT_DUV,
> + IIO_MOD_PM1,
> + IIO_MOD_PM2P5,
> + IIO_MOD_PM4,
> + IIO_MOD_PM10,
> };
>
> enum iio_event_type {
> diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> index ac2de6b7e89f..f6b8003fbe3c 100644
> --- a/tools/iio/iio_event_monitor.c
> +++ b/tools/iio/iio_event_monitor.c
> @@ -60,6 +60,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_GRAVITY] = "gravity",
> [IIO_POSITIONRELATIVE] = "positionrelative",
> [IIO_PHASE] = "phase",
> + [IIO_MASSCO
Re: [PATCH v3 1/3] iio: Add modifiers for ethanol and H2 gases
On Thu, Dec 13, 2018 at 6:44 AM Andreas Brauchli
wrote:
>
> Add ethanol and H2 gas modifiers:
> * IIO_MOD_ETHANOL
Was going to ask why this wasn't a chemical formula like the rest of
the modifiers, but C2H6O would be a bit wordy/unclear :).
> * IIO_MOD_H2
>
Acked-by: Matt Ranostay
> Signed-off-by: Andreas Brauchli
> ---
> Documentation/ABI/testing/sysfs-bus-iio | 4
> include/uapi/linux/iio/types.h | 2 ++
> tools/iio/iio_event_monitor.c | 4
> 3 files changed, 10 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> b/Documentation/ABI/testing/sysfs-bus-iio
> index 8127a08e366d..6d64521bf565 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -1554,6 +1554,10 @@ What:
> /sys/bus/iio/devices/iio:deviceX/in_concentration_raw
> What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_raw
> What: /sys/bus/iio/devices/iio:deviceX/in_concentration_co2_raw
> What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_co2_raw
> +What: /sys/bus/iio/devices/iio:deviceX/in_concentration_ethanol_raw
> +What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_ethanol_raw
> +What: /sys/bus/iio/devices/iio:deviceX/in_concentration_h2_raw
> +What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_h2_raw
> What: /sys/bus/iio/devices/iio:deviceX/in_concentration_voc_raw
> What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_voc_raw
> KernelVersion: 4.3
> diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> index 92baabc103ac..04a6649fa442 100644
> --- a/include/uapi/linux/iio/types.h
> +++ b/include/uapi/linux/iio/types.h
> @@ -87,6 +87,8 @@ enum iio_modifier {
> IIO_MOD_VOC,
> IIO_MOD_LIGHT_UV,
> IIO_MOD_LIGHT_DUV,
> + IIO_MOD_ETHANOL,
> + IIO_MOD_H2,
> };
>
> enum iio_event_type {
> diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> index ac2de6b7e89f..f29c885f4b28 100644
> --- a/tools/iio/iio_event_monitor.c
> +++ b/tools/iio/iio_event_monitor.c
> @@ -114,6 +114,8 @@ static const char * const iio_modifier_names[] = {
> [IIO_MOD_I] = "i",
> [IIO_MOD_Q] = "q",
> [IIO_MOD_CO2] = "co2",
> + [IIO_MOD_ETHANOL] = "ethanol",
> + [IIO_MOD_H2] = "h2",
> [IIO_MOD_VOC] = "voc",
> };
>
> @@ -199,6 +201,8 @@ static bool event_is_known(struct iio_event_data *event)
> case IIO_MOD_I:
> case IIO_MOD_Q:
> case IIO_MOD_CO2:
> + case IIO_MOD_ETHANOL:
> + case IIO_MOD_H2:
> case IIO_MOD_VOC:
> break;
> default:
> --
> 2.17.1
>
Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type
On Sat, Dec 1, 2018 at 5:48 PM Jonathan Cameron
wrote:
>
> On Sun, 25 Nov 2018 16:44:23 +0100
> Tomasz Duszynski wrote:
>
> > On Sun, Nov 25, 2018 at 06:14:44AM -0800, Matt Ranostay wrote:
> > > On Sun, Nov 25, 2018 at 6:03 AM Jonathan Cameron
> > > wrote:
> > > >
> > > > On Sun, 25 Nov 2018 05:51:32 -0800
> > > > Matt Ranostay wrote:
> > > >
> > > > > On Sat, Nov 24, 2018 at 2:14 PM Tomasz Duszynski
> > > > > wrote:
> > > > > >
> > > > > > Measuring particulate matter in ug / m3 (micro-grams per cubic
> > > > > > meter)
> > > > > > is de facto standard. Existing air quality sensors usually follow
> > > > > > this convention and are capable of returning measurements using
> > > > > > this unit.
> > > > > >
> > > > > > IIO currently does not offer suitable channel type for this
> > > > > > type of measurements hence this patch adds this.
> > > > > >
> > > > > > In addition, two modifiers are introduced used for distinguishing
> > > > > > between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> > > > > > IIO_MOD_PM10 and IIO_MOD_PM2p5.
> > > > > >
> > > > > > Signed-off-by: Tomasz Duszynski
> > > > > > ---
> > > > > > Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> > > > > > drivers/iio/industrialio-core.c | 3 +++
> > > > > > include/uapi/linux/iio/types.h | 3 +++
> > > > > > tools/iio/iio_event_monitor.c | 6 ++
> > > > > > 4 files changed, 22 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> > > > > > b/Documentation/ABI/testing/sysfs-bus-iio
> > > > > > index 8127a08e366d..ce0ed140660d 100644
> > > > > > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > > > > > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > > > > > @@ -1684,4 +1684,13 @@ KernelVersion: 4.18
> > > > > > Contact: linux-...@vger.kernel.org
> > > > > > Description:
> > > > > > Raw (unscaled) phase difference reading from
> > > > > > channel Y
> > > > > > - that can be processed to radians.
> > > > > > \ No newline at end of file
> > > > > > + that can be processed to radians.
> > > > > > +
> > > > > > +What:
> > > > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> > > > > > +What:
> > > > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> > > > > > +What:
> > > > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> > > > > > +What:
> > > > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> > > > > > +KernelVersion: 4.21
> > > > > > +Contact: linux-...@vger.kernel.org
> > > > > > +Description:
> > > > > > + Mass concentration reading of particulate matter in
> > > > > > ug / m3.
> > > > > > diff --git a/drivers/iio/industrialio-core.c
> > > > > > b/drivers/iio/industrialio-core.c
> > > > > > index a062cfddc5af..2a9ef600c1fb 100644
> > > > > > --- a/drivers/iio/industrialio-core.c
> > > > > > +++ b/drivers/iio/industrialio-core.c
> > > > > > @@ -87,6 +87,7 @@ static const char * const
> > > > > > iio_chan_type_name_spec[] = {
> > > > > > [IIO_GRAVITY] = "gravity",
> > > > > > [IIO_POSITIONRELATIVE] = "positionrelative",
> > > > > > [IIO_PHASE] = "phase",
> > > > > > + [IIO_MASSCONCENTRATION] = "massconcentration",
> > > > > > };
> > > > > >
> > > > > > static const char * const iio_modifier_names[] = {
> > > > > > @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[]
> > > > > > = {
> > > > > > [IIO_MOD_Q] = "q",
> > &g
Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type
On Sun, Nov 25, 2018 at 6:03 AM Jonathan Cameron
wrote:
>
> On Sun, 25 Nov 2018 05:51:32 -0800
> Matt Ranostay wrote:
>
> > On Sat, Nov 24, 2018 at 2:14 PM Tomasz Duszynski wrote:
> > >
> > > Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> > > is de facto standard. Existing air quality sensors usually follow
> > > this convention and are capable of returning measurements using
> > > this unit.
> > >
> > > IIO currently does not offer suitable channel type for this
> > > type of measurements hence this patch adds this.
> > >
> > > In addition, two modifiers are introduced used for distinguishing
> > > between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> > > IIO_MOD_PM10 and IIO_MOD_PM2p5.
> > >
> > > Signed-off-by: Tomasz Duszynski
> > > ---
> > > Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> > > drivers/iio/industrialio-core.c | 3 +++
> > > include/uapi/linux/iio/types.h | 3 +++
> > > tools/iio/iio_event_monitor.c | 6 ++
> > > 4 files changed, 22 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> > > b/Documentation/ABI/testing/sysfs-bus-iio
> > > index 8127a08e366d..ce0ed140660d 100644
> > > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > > @@ -1684,4 +1684,13 @@ KernelVersion: 4.18
> > > Contact: linux-...@vger.kernel.org
> > > Description:
> > > Raw (unscaled) phase difference reading from channel Y
> > > - that can be processed to radians.
> > > \ No newline at end of file
> > > + that can be processed to radians.
> > > +
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> > > +KernelVersion: 4.21
> > > +Contact: linux-...@vger.kernel.org
> > > +Description:
> > > + Mass concentration reading of particulate matter in ug /
> > > m3.
> > > diff --git a/drivers/iio/industrialio-core.c
> > > b/drivers/iio/industrialio-core.c
> > > index a062cfddc5af..2a9ef600c1fb 100644
> > > --- a/drivers/iio/industrialio-core.c
> > > +++ b/drivers/iio/industrialio-core.c
> > > @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] = {
> > > [IIO_GRAVITY] = "gravity",
> > > [IIO_POSITIONRELATIVE] = "positionrelative",
> > > [IIO_PHASE] = "phase",
> > > + [IIO_MASSCONCENTRATION] = "massconcentration",
> > > };
> > >
> > > static const char * const iio_modifier_names[] = {
> > > @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
> > > [IIO_MOD_Q] = "q",
> > > [IIO_MOD_CO2] = "co2",
> > > [IIO_MOD_VOC] = "voc",
> > > + [IIO_MOD_PM2p5] = "pm2p5",
> > > + [IIO_MOD_PM10] = "pm10",
> > > };
> > >
> > > /* relies on pairs of these shared then separate */
> > > diff --git a/include/uapi/linux/iio/types.h
> > > b/include/uapi/linux/iio/types.h
> > > index 92baabc103ac..465044b42af5 100644
> > > --- a/include/uapi/linux/iio/types.h
> > > +++ b/include/uapi/linux/iio/types.h
> > > @@ -46,6 +46,7 @@ enum iio_chan_type {
> > > IIO_GRAVITY,
> > > IIO_POSITIONRELATIVE,
> > > IIO_PHASE,
> > > + IIO_MASSCONCENTRATION,
> >
> > So I'm guessing IIO_CONCENTRATION can't be scaled to the micro-grams
> > per cubic meter?
>
> Currently concentration is defined as a percentage reading of a substance
> (which does make me wonder if it is meant to be percentage of the volume or
> percentage of the mass?) Either way, if can't convert to a density
> measurement
> as it's a unit free ratio (I think).
Seems like it can be both.. guessing all the atmosphere ( CO2, VOC,
etc) ones are mass/density because on how they work.
But the electro-conductivity sensor that is u
Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type
On Sat, Nov 24, 2018 at 2:14 PM Tomasz Duszynski wrote:
>
> Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> is de facto standard. Existing air quality sensors usually follow
> this convention and are capable of returning measurements using
> this unit.
>
> IIO currently does not offer suitable channel type for this
> type of measurements hence this patch adds this.
>
> In addition, two modifiers are introduced used for distinguishing
> between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> IIO_MOD_PM10 and IIO_MOD_PM2p5.
>
> Signed-off-by: Tomasz Duszynski
> ---
> Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> drivers/iio/industrialio-core.c | 3 +++
> include/uapi/linux/iio/types.h | 3 +++
> tools/iio/iio_event_monitor.c | 6 ++
> 4 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> b/Documentation/ABI/testing/sysfs-bus-iio
> index 8127a08e366d..ce0ed140660d 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -1684,4 +1684,13 @@ KernelVersion: 4.18
> Contact: linux-...@vger.kernel.org
> Description:
> Raw (unscaled) phase difference reading from channel Y
> - that can be processed to radians.
> \ No newline at end of file
> + that can be processed to radians.
> +
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> +KernelVersion: 4.21
> +Contact: linux-...@vger.kernel.org
> +Description:
> + Mass concentration reading of particulate matter in ug / m3.
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index a062cfddc5af..2a9ef600c1fb 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_GRAVITY] = "gravity",
> [IIO_POSITIONRELATIVE] = "positionrelative",
> [IIO_PHASE] = "phase",
> + [IIO_MASSCONCENTRATION] = "massconcentration",
> };
>
> static const char * const iio_modifier_names[] = {
> @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
> [IIO_MOD_Q] = "q",
> [IIO_MOD_CO2] = "co2",
> [IIO_MOD_VOC] = "voc",
> + [IIO_MOD_PM2p5] = "pm2p5",
> + [IIO_MOD_PM10] = "pm10",
> };
>
> /* relies on pairs of these shared then separate */
> diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> index 92baabc103ac..465044b42af5 100644
> --- a/include/uapi/linux/iio/types.h
> +++ b/include/uapi/linux/iio/types.h
> @@ -46,6 +46,7 @@ enum iio_chan_type {
> IIO_GRAVITY,
> IIO_POSITIONRELATIVE,
> IIO_PHASE,
> + IIO_MASSCONCENTRATION,
So I'm guessing IIO_CONCENTRATION can't be scaled to the micro-grams
per cubic meter?
> };
>
> enum iio_modifier {
> @@ -87,6 +88,8 @@ enum iio_modifier {
> IIO_MOD_VOC,
> IIO_MOD_LIGHT_UV,
> IIO_MOD_LIGHT_DUV,
> + IIO_MOD_PM2p5,
I know this is unit of measure but the lowercase p in IIO_MOD_PM2p5 is
a bit non-standard for iio defines/enum.
- Matt
> + IIO_MOD_PM10,
> };
>
> enum iio_event_type {
> diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> index ac2de6b7e89f..f0fcfeddba2b 100644
> --- a/tools/iio/iio_event_monitor.c
> +++ b/tools/iio/iio_event_monitor.c
> @@ -60,6 +60,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_GRAVITY] = "gravity",
> [IIO_POSITIONRELATIVE] = "positionrelative",
> [IIO_PHASE] = "phase",
> + [IIO_MASSCONCENTRATION] = "massconcentration",
> };
>
> static const char * const iio_ev_type_text[] = {
> @@ -115,6 +116,8 @@ static const char * const iio_modifier_names[] = {
> [IIO_MOD_Q] = "q",
> [IIO_MOD_CO2] = "co2",
> [IIO_MOD_VOC] = "voc",
> + [IIO_MOD_PM2p5] = "pm2p5",
> + [IIO_MOD_PM10] = "pm10",
> };
>
> static bool event_is_known(struct iio_event_data *event)
> @@ -156,6 +159,7 @@ static bool event_is_known(struct iio_event_data *event)
> case IIO_GRAVITY:
> case IIO_POSITIONRELATIVE:
> case IIO_PHASE:
> + case IIO_MASSCONCENTRATION:
> break;
> default:
> return false;
> @@ -200,6 +204,8 @@ static bool event_is_known(struct iio_event_data *event)
> case IIO_MOD_Q:
> case IIO_MOD_CO2:
> case IIO_MOD_VOC:
> + case IIO_MOD_PM2p5:
> + case IIO_MOD_PM10:
> break;
> default:
> return false;
> --
> 2.19.2
>
Re: [PATCH] iio: adc: ina2xx: fix missing break statement
On Tue, Oct 9, 2018 at 5:09 AM Colin King wrote:
>
> From: Colin Ian King
>
> The IIO_CHAN_INFO_SCALE case is missing a break statement and in
> the unlikely event that chan->address is not matched in the nested
> switch statement then the code falls through to the following
> IIO_CHAN_INFO_HARDWAREGAIN case. Fix this by adding the missing
> break. While we are fixing this, it's probably a good idea to
> add in a break statement to the IIO_CHAN_INFO_HARDWAREGAIN case
> too (this is a moot point).
>
> Detected by CoverityScan, CID#1462408 ("Missing break in switch")
I'm not familiar with running Coverity scans myself, but is this CID
some publicly accessible report?
If it is an in-house scan then it should be dropped IMHO
- Matt
>
> Fixes: ca6a2d86acae ("iio: adc: ina2xx: Allow setting Shunt Voltage PGA gain
> and Bus Voltage range")
> Signed-off-by: Colin Ian King
> ---
> drivers/iio/adc/ina2xx-adc.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/iio/adc/ina2xx-adc.c b/drivers/iio/adc/ina2xx-adc.c
> index d1239624187d..9bc5986780b9 100644
> --- a/drivers/iio/adc/ina2xx-adc.c
> +++ b/drivers/iio/adc/ina2xx-adc.c
> @@ -250,6 +250,7 @@ static int ina2xx_read_raw(struct iio_dev *indio_dev,
> *val2 = chip->shunt_resistor_uohm;
> return IIO_VAL_FRACTIONAL;
> }
> + break;
>
> case IIO_CHAN_INFO_HARDWAREGAIN:
> switch (chan->address) {
> @@ -262,6 +263,7 @@ static int ina2xx_read_raw(struct iio_dev *indio_dev,
> *val = chip->range_vbus == 32 ? 1 : 2;
> return IIO_VAL_INT;
> }
> + break;
> }
>
> return -EINVAL;
> --
> 2.17.1
>
Re: [PATCH] iio: proximity: lidar-v2: replace i2c block access method with the one already implemented.
On Wed, Sep 12, 2018 at 8:51 PM Song Qiang wrote:
>
> This driver tries to access a block of data on a i2c bus and it tries
> to manually make a device command frame and a consecutively read frame,
> then uses i2c_transfer() to read data. But this has already been
> implemented in i2c_smbus_read_i2c_block_data().
> Sorry for not having this device by my hand, which is a little expansive
> for me, but I have another i2c device and tested with both i2c_transfer()
> and i2c_smbus_read_i2c_block_data() and they all ends the same.
> I'm not familiar with the SMBus, don't know if the lidar_smbus_xfer()
> function is the same as i2c_smbus_read_block_data()? The original code
> is commented with something I'm not sure, but I think if it's a standard
> SMBus, it should be able to use in here.
> Hoping for someone to explain.
>
Yes actually there is a reason for this insanity!
It isn't actually SMBUS (note the lidar_smbus_xfer function below it)
and has a odd way to read registers via I2C.
Basically the I2C_M_STOP flags is the reason you can use the standard
i2c_smbus_read_i2c_block_data().
Page 6 in this datasheet
*
http://static.garmin.com/pumac/LIDAR_Lite_v3_Operation_Manual_and_Technical_Specifications.pdf
> Signed-off-by: Song Qiang
> ---
> .../iio/proximity/pulsedlight-lidar-lite-v2.c | 18 +-
> 1 file changed, 1 insertion(+), 17 deletions(-)
>
> diff --git a/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
> b/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
> index 47af54f14756..ca880ba8e820 100644
> --- a/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
> +++ b/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
> @@ -63,23 +63,7 @@ static const struct iio_chan_spec lidar_channels[] = {
>
> static int lidar_i2c_xfer(struct lidar_data *data, u8 reg, u8 *val, int len)
> {
> - struct i2c_client *client = data->client;
> - struct i2c_msg msg[2];
> - int ret;
> -
> - msg[0].addr = client->addr;
> - msg[0].flags = client->flags | I2C_M_STOP;
> - msg[0].len = 1;
> - msg[0].buf = (char *) ®
> -
> - msg[1].addr = client->addr;
> - msg[1].flags = client->flags | I2C_M_RD;
> - msg[1].len = len;
> - msg[1].buf = (char *) val;
> -
> - ret = i2c_transfer(client->adapter, msg, 2);
> -
> - return (ret == 2) ? 0 : -EIO;
> + return i2c_smbus_read_i2c_block_data(data->client, reg, len, val);
> }
>
> static int lidar_smbus_xfer(struct lidar_data *data, u8 reg, u8 *val, int
> len)
> --
> 2.17.1
>
Re: [PATCH v3] iio: chemical: Add support for Bosch BME680 sensor
On Wed, Jul 11, 2018 at 5:13 AM, Himanshu Jha wrote: > Bosch BME680 is a 4-in-1 sensor with temperature, pressure, humidity > and gas sensing capability. It supports both I2C and SPI communication > protocol for effective data communication. > > The device supports two modes: > > 1. Sleep mode > 2. Forced mode > > The measurements only takes place when forced mode is triggered and a > single TPHG cycle is performed by the sensor. The sensor automatically > goes to sleep after afterwards. > > The device has various calibration constants/parameters programmed into > devices' non-volatile memory(NVM) during production and can't be altered > by the user. These constants are used in the compensation functions to > get the required compensated readings along with the raw data. The > compensation functions/algorithms are provided by Bosch Sensortec GmbH > via their API[1]. As these don't change during the measurement cycle, > therefore we read and store them at the probe. The default configs > supplied by Bosch are also set at probe. > > 0-day tested with build success. > > GSoC-2018: https://summerofcode.withgoogle.com/projects/#6691473790074880 > Mentor: Daniel Baluta > [1] https://github.com/BoschSensortec/BME680_driver > Datasheet: > https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BME680-DS001-00.pdf > > Cc: Daniel Baluta > Signed-off-by: Himanshu Jha > --- > > v3: >-moved files to chemical directory instead of a dedicated directory. >-read calibration parameters serially with endian conversions. >-drop some return ret. >-removed few unnecessary casts safely. >-added 'u' suffix to explicitly specify unsigned for large values > and thereby fixing comiler warning. >-left aligned all comments. >-added a comment explaining heater stability failure. > > v2: >-Used devm_add_action() to add a generic remove method for > both I2C & SPI driver. >-Introduction of compensation functions. >-chip initialisation routines moved to respective I2C and SPI > driver. >-Introduction of gas sensing rountines. >-Simplified Kconfig to reduce various options. > > drivers/iio/chemical/Kconfig | 25 + > drivers/iio/chemical/Makefile | 3 + > drivers/iio/chemical/bme680.h | 99 > drivers/iio/chemical/bme680_core.c | 946 > + > drivers/iio/chemical/bme680_i2c.c | 83 > drivers/iio/chemical/bme680_spi.c | 123 + > 6 files changed, 1279 insertions(+) > create mode 100644 drivers/iio/chemical/bme680.h > create mode 100644 drivers/iio/chemical/bme680_core.c > create mode 100644 drivers/iio/chemical/bme680_i2c.c > create mode 100644 drivers/iio/chemical/bme680_spi.c > > diff --git a/drivers/iio/chemical/Kconfig b/drivers/iio/chemical/Kconfig > index 5cb5be7..24790a8 100644 > --- a/drivers/iio/chemical/Kconfig > +++ b/drivers/iio/chemical/Kconfig > @@ -21,6 +21,31 @@ config ATLAS_PH_SENSOR > To compile this driver as module, choose M here: the > module will be called atlas-ph-sensor. > > +config BME680 > + tristate "Bosch Sensortec BME680 sensor driver" > + depends on (I2C || SPI) > + select REGMAP > + select BME680_I2C if (I2C) > + select BME680_SPI if (SPI) Don't think you actually need parentheses around any of these, but of course then again doesn't hurt > + help > + Say yes here to build support for Bosch Sensortec BME680 sensor with > + temperature, pressure, humidity and gas sensing capability. > + > + This driver can also be built as a module. If so, the module for I2C > + would be called bme680_i2c and bme680_spi for SPI support. > + > +config BME680_I2C > + tristate > + depends on BME680 > + depends on I2C Wouldn't "depends on I2C && BME680" be cleaner? Maybe someone else here can tell me if I'm too nit-picky :) > + select REGMAP_I2C > + > +config BME680_SPI > + tristate > + depends on BME680 > + depends on SPI Same only with SPI > + select REGMAP_SPI > + > config CCS811 > tristate "AMS CCS811 VOC sensor" > depends on I2C > diff --git a/drivers/iio/chemical/Makefile b/drivers/iio/chemical/Makefile > index a629b29..2f4c4ba 100644 > --- a/drivers/iio/chemical/Makefile > +++ b/drivers/iio/chemical/Makefile > @@ -4,6 +4,9 @@ > > # When adding new entries keep the list in alphabetical order > obj-$(CONFIG_ATLAS_PH_SENSOR) += atlas-ph-sensor.o > +obj-$(CONFIG_BME680) += bme680_core.o > +obj-$(CONFIG_BME680_I2C) += bme680_i2c.o > +obj-$(CONFIG_BME680_SPI) += bme680_spi.o > obj-$(CONFIG_CCS811) += ccs811.o > obj-$(CONFIG_IAQCORE) += ams-iaq-core.o > obj-$(CONFIG_VZ89X)+= vz89x.o > diff --git a/drivers/iio/chemical/bme680.h b/drivers/iio/chemical/bme680.h > new file mode 100644 > index 000..80c4190 > --- /dev/null > +++ b/drivers/iio/chemical/bme680.h > @@ -0,0 +1,99 @@ > +/* SPDX-Licen
[PATCH] tsl2550: fix lux1_input error in low light
ADC channel 0 photodiode detects both infrared + visible light, but ADC channel 1 just detects infrared. However, the latter is a bit more sensitive in that range so complete darkness or low light causes a error condition in which the chan0 - chan1 is negative that results in a -EAGAIN. This patch changes the resulting lux1_input sysfs attribute message from "Resource temporarily unavailable" to a user-grokable lux value of 0. Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Signed-off-by: Matt Ranostay --- drivers/misc/tsl2550.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/misc/tsl2550.c b/drivers/misc/tsl2550.c index adf46072cb37..3fce3b6a3624 100644 --- a/drivers/misc/tsl2550.c +++ b/drivers/misc/tsl2550.c @@ -177,7 +177,7 @@ static int tsl2550_calculate_lux(u8 ch0, u8 ch1) } else lux = 0; else - return -EAGAIN; + return 0; /* LUX range check */ return lux > TSL2550_MAX_LUX ? TSL2550_MAX_LUX : lux; -- 2.14.1
Re: [RFC PATCH 1/1] power: supply: bq27xxx: Call power_supply_changed on status change
Commit message please :)
On Tue, Feb 27, 2018 at 5:04 PM, Merlijn Wajer wrote:
> Signed-off-by: Merlijn Wajer
> ---
Single patch changes usually don't have a cover letter. you put more
detail here in the cutoff section (aka after --- above)
> drivers/power/supply/bq27xxx_battery.c | 59
> +-
> include/linux/power/bq27xxx_battery.h | 1 +
> 2 files changed, 30 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/power/supply/bq27xxx_battery.c
> b/drivers/power/supply/bq27xxx_battery.c
> index 0a203672744c..218d153fb431 100644
> --- a/drivers/power/supply/bq27xxx_battery.c
> +++ b/drivers/power/supply/bq27xxx_battery.c
> @@ -1527,6 +1527,31 @@ static int bq27xxx_battery_read_health(struct
> bq27xxx_device_info *di)
> return POWER_SUPPLY_HEALTH_GOOD;
> }
>
> +static int bq27xxx_battery_read_status(struct bq27xxx_device_info *di)
> +{
> + int status;
> +
> + if (di->opts & BQ27XXX_O_ZERO) {
> + if (di->cache.flags & BQ27000_FLAG_FC)
> + status = POWER_SUPPLY_STATUS_FULL;
> + else if (di->cache.flags & BQ27000_FLAG_CHGS)
> + status = POWER_SUPPLY_STATUS_CHARGING;
> + else if (power_supply_am_i_supplied(di->bat) > 0)
> + status = POWER_SUPPLY_STATUS_NOT_CHARGING;
> + else
> + status = POWER_SUPPLY_STATUS_DISCHARGING;
> + } else {
> + if (di->cache.flags & BQ27XXX_FLAG_FC)
> + status = POWER_SUPPLY_STATUS_FULL;
> + else if (di->cache.flags & BQ27XXX_FLAG_DSC)
> + status = POWER_SUPPLY_STATUS_DISCHARGING;
> + else
> + status = POWER_SUPPLY_STATUS_CHARGING;
> + }
> +
> + return status;
> +}
> +
> void bq27xxx_battery_update(struct bq27xxx_device_info *di)
> {
> struct bq27xxx_reg_cache cache = {0, };
> @@ -1547,6 +1572,7 @@ void bq27xxx_battery_update(struct bq27xxx_device_info
> *di)
> cache.time_to_full = -ENODATA;
> cache.charge_full = -ENODATA;
> cache.health = -ENODATA;
> + cache.status = bq27xxx_battery_read_status(di);
> } else {
> if (di->regs[BQ27XXX_REG_TTE] != INVALID_REG_ADDR)
> cache.time_to_empty =
> bq27xxx_battery_read_time(di, BQ27XXX_REG_TTE);
> @@ -1559,6 +1585,7 @@ void bq27xxx_battery_update(struct bq27xxx_device_info
> *di)
> if (di->regs[BQ27XXX_REG_AE] != INVALID_REG_ADDR)
> cache.energy =
> bq27xxx_battery_read_energy(di);
> cache.health = bq27xxx_battery_read_health(di);
> + cache.status = bq27xxx_battery_read_status(di);
> }
> if (di->regs[BQ27XXX_REG_CYCT] != INVALID_REG_ADDR)
> cache.cycle_count = bq27xxx_battery_read_cyct(di);
> @@ -1570,7 +1597,7 @@ void bq27xxx_battery_update(struct bq27xxx_device_info
> *di)
> di->charge_design_full =
> bq27xxx_battery_read_dcap(di);
> }
>
> - if (di->cache.capacity != cache.capacity)
> + if ((di->cache.capacity != cache.capacity) || (di->cache.status !=
> cache.status))
> power_supply_changed(di->bat);
>
> if (memcmp(&di->cache, &cache, sizeof(cache)) != 0)
> @@ -1625,34 +1652,6 @@ static int bq27xxx_battery_current(struct
> bq27xxx_device_info *di,
> return 0;
> }
>
> -static int bq27xxx_battery_status(struct bq27xxx_device_info *di,
> - union power_supply_propval *val)
> -{
> - int status;
> -
> - if (di->opts & BQ27XXX_O_ZERO) {
> - if (di->cache.flags & BQ27000_FLAG_FC)
> - status = POWER_SUPPLY_STATUS_FULL;
> - else if (di->cache.flags & BQ27000_FLAG_CHGS)
> - status = POWER_SUPPLY_STATUS_CHARGING;
> - else if (power_supply_am_i_supplied(di->bat) > 0)
> - status = POWER_SUPPLY_STATUS_NOT_CHARGING;
> - else
> - status = POWER_SUPPLY_STATUS_DISCHARGING;
> - } else {
> - if (di->cache.flags & BQ27XXX_FLAG_FC)
> - status = POWER_SUPPLY_STATUS_FULL;
> - else if (di->cache.flags & BQ27XXX_FLAG_DSC)
> - status = POWER_SUPPLY_STATUS_DISCHARGING;
> - else
> - status = POWER_SUPPLY_STATUS_CHARGING;
> - }
> -
> - val->intval = status;
> -
> - return 0;
> -}
> -
> static int bq27xxx_battery_capacity_level(struct bq27xxx_device_info *di,
> union power_supply_propval *val)
> {
> @@ -1733,7 +1732,7 @@ static int bq27xxx_battery_get_property(struct
> power_su
Re: [PATCH v2] IIO: bmp280-core.c: fix error in humidity calculation
On Mon, Apr 10, 2017 at 10:00 AM, Andreas Klinger wrote: > While calculating the compensation of the humidity there are negative values > interpreted as unsigned because of unsigned variables used. These values as > well as the constants need to be casted to signed as indicated by the > documentation of the sensor. > > Changes in v2: > - cast also constants to signed; otherwise calculation is not correct > > I removed the Acked-By of Linus Walleij because of another change in the > calculation. Don't know how it should be treated. > > Signed-off-by: Andreas Klinger Reviewed-by: Matt Ranostay > --- > drivers/iio/pressure/bmp280-core.c | 11 ++- > 1 file changed, 6 insertions(+), 5 deletions(-) > > diff --git a/drivers/iio/pressure/bmp280-core.c > b/drivers/iio/pressure/bmp280-core.c > index 4d18826ac63c..d82b788374b6 100644 > --- a/drivers/iio/pressure/bmp280-core.c > +++ b/drivers/iio/pressure/bmp280-core.c > @@ -175,11 +175,12 @@ static u32 bmp280_compensate_humidity(struct > bmp280_data *data, > } > H6 = sign_extend32(tmp, 7); > > - var = ((s32)data->t_fine) - 76800; > - var = adc_humidity << 14) - (H4 << 20) - (H5 * var)) + 16384) >> > 15) > - * (((var * H6) >> 10) * (((var * H3) >> 11) + 32768)) >> > 10) > - + 2097152) * H2 + 8192) >> 14); > - var -= var >> 15) * (var >> 15)) >> 7) * H1) >> 4; > + var = ((s32)data->t_fine) - (s32)76800; > + var = adc_humidity << 14) - (H4 << 20) - (H5 * var)) > + + (s32)16384) >> 15) * (((var * H6) >> 10) > + * (((var * (s32)H3) >> 11) + (s32)32768)) >> 10) > + + (s32)2097152) * H2 + 8192) >> 14); > + var -= var >> 15) * (var >> 15)) >> 7) * (s32)H1) >> 4; > > return var >> 12; > }; > -- > 2.1.4 > > > --
Re: [PATCH] IIO: bmp280-core.c: fix error in humidity calculation
On Fri, Apr 7, 2017 at 12:27 PM, Andreas Klinger wrote:
> Hi Matt,
>
> i've extracted the error condition in a small userspace application for
> demonstration. Just compile and see that in this case the variable H3 is zero
> but the whole term evaluates differently if treated as unsigned or signed.
>
> The whole example including the values of the variables are taken from the
> real
> driver.
>
Ok now I see what you are referencing from the datasheet, and can
confirm the values are incorrect.
Just a suggestion rather than have all those casts it would be easier
to just change H1 and H3 types
to signed integers.
Thanks,
Matt
> Andreas
>
>
> Now the example:
>
> ---
>
> /*
> * humidity.c
> * this test program is just for demonstrating the difference in the
> * calculation of humidity compensation with BME280 sensor
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2 as
> * published by the Free Software Foundation.
> *
> */
>
> #include
> #include
>
> int main(int argn, char* argv[])
> {
> int adc_humidity = 28275;
> int t_fine = 50623;
> unsigned int H1 = 75, H3 = 0;
> int H2 = 360, H4 = 324, H5 = 0, H6 = 30;
> int var;
>
> var = -26177;
> /* extracted errornous term with cast */
> printf("with cast:%d\n", (((var * H6) >> 10) * (((var * (int)H3)
> >> 11)
> + (int)32768)) >> 10);
> /* extracted errornous term now without a cast */
> printf("without cast: %d\n", (((var * H6) >> 10) * (((var * H3) >> 11)
> + 32768)) >> 10);
>
> printf("\n");
> printf("t_fine: %d; humidity: %d\nH: %d; %d; %d; %d; %d; %d\n",
> t_fine, adc_humidity, H1, H2, H3, H4, H5, H6);
> printf("\n");
>
> /* the whole example taken from the driver */
> /* with the cast as proposed by the documentation */
> var = ((int)t_fine) - (int)76800;
> var = adc_humidity << 14) - (H4 << 20) - (H5 * var))
> + (int)16384) >> 15) * (((var * H6) >> 10)
> * (((var * (int)H3) >> 11) + (int)32768)) >> 10)
> + (int)2097152) * H2 + 8192) >> 14);
> var -= var >> 15) * (var >> 15)) >> 7) * (int)H1) >> 4;
>
> printf("with cast:var: %d\n", var>>12);
> printf("\n");
>
> /* now the same calculation without the cast */
> var = (t_fine) - 76800;
> var = adc_humidity << 14) - (H4 << 20) - (H5 * var))
> + 16384) >> 15) * (((var * H6) >> 10)
> * (((var * H3) >> 11) + 32768)) >> 10)
> + 2097152) * H2 + 8192) >> 14);
> var -= var >> 15) * (var >> 15)) >> 7) * H1) >> 4;
>
> printf("without cast: var: %d\n", var>>12);
>
> return 0;
> }
>
> ---
>
> Output:
>
> with cast:-24544
> without cast: 4169760
>
> t_fine: 50623; humidity: 28275
> H: 75; 360; 0; 324; 0; 30
>
> with cast:var: 41671
>
> without cast: var: 124497
>
> ---
>
> Matt Ranostay schrieb am Thu, 06. Apr 23:13:
>> On Mon, Apr 3, 2017 at 11:16 PM, Matt Ranostay
>> wrote:
>> > On Sun, Apr 2, 2017 at 10:29 AM, Andreas Klinger
>> > wrote:
>> >> Linus Walleij schrieb am Sun, 02. Apr 16:56:
>> >>> On Sun, Apr 2, 2017 at 11:32 AM, Jonathan Cameron
>> >>> wrote:
>> >>> > On 27/03/17 11:06, Andreas Klinger wrote:
>> >>> >> While calculating the compensation of the humidity there are negative
>> >>> >> values interpreted as unsigned because of unsigned variables used.
>> >>> >> These values need to be casted to signed as indicated by the
>> >>> >> documentation
>> >>> >> of the sensor.
>> >>> >>
>> >>> >> Signed-off-by: Andreas Klinger
>> >>> >
>> >>> > Looks superficially right to me, but would like an Ack from Linus
>> >>> > Walleij.
>> >>>
>> >>> I didn't work on these calculations, only infrastructure for the driver
>> >>> but FWIW:
>> &g
Re: [PATCH] IIO: bmp280-core.c: fix error in humidity calculation
On Mon, Apr 3, 2017 at 11:16 PM, Matt Ranostay wrote: > On Sun, Apr 2, 2017 at 10:29 AM, Andreas Klinger wrote: >> Linus Walleij schrieb am Sun, 02. Apr 16:56: >>> On Sun, Apr 2, 2017 at 11:32 AM, Jonathan Cameron wrote: >>> > On 27/03/17 11:06, Andreas Klinger wrote: >>> >> While calculating the compensation of the humidity there are negative >>> >> values interpreted as unsigned because of unsigned variables used. >>> >> These values need to be casted to signed as indicated by the >>> >> documentation >>> >> of the sensor. >>> >> >>> >> Signed-off-by: Andreas Klinger >>> > >>> > Looks superficially right to me, but would like an Ack from Linus Walleij. >>> >>> I didn't work on these calculations, only infrastructure for the driver >>> but FWIW: >>> Acked-by: Linus Walleij >>> >>> Matt Ranostay @Intel is the person you probably want to ACK it though, >>> he added the humidity calculations :) >> >> It just turned out that there must be another error in the calculation. I'll >> fix >> and test it first. >> >> When i'm done i'll send a new version of the patch. >> > > Ok will hold off till review till the next patchset... BTW this > datasheet's calculations made my eyes bleed so it is quiet likely it > has bugs... Hmm the datatypes you are casting to s32 are already signed integers... Interested in what you found on what the actual bug is. > > Thanks, > > Matt > >> Andreas >> >>> >>> Yours, >>> Linus Walleij >> >> -- >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-iio" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IIO: bmp280-core.c: fix error in humidity calculation
On Sun, Apr 2, 2017 at 10:29 AM, Andreas Klinger wrote: > Linus Walleij schrieb am Sun, 02. Apr 16:56: >> On Sun, Apr 2, 2017 at 11:32 AM, Jonathan Cameron wrote: >> > On 27/03/17 11:06, Andreas Klinger wrote: >> >> While calculating the compensation of the humidity there are negative >> >> values interpreted as unsigned because of unsigned variables used. >> >> These values need to be casted to signed as indicated by the documentation >> >> of the sensor. >> >> >> >> Signed-off-by: Andreas Klinger >> > >> > Looks superficially right to me, but would like an Ack from Linus Walleij. >> >> I didn't work on these calculations, only infrastructure for the driver >> but FWIW: >> Acked-by: Linus Walleij >> >> Matt Ranostay @Intel is the person you probably want to ACK it though, >> he added the humidity calculations :) > > It just turned out that there must be another error in the calculation. I'll > fix > and test it first. > > When i'm done i'll send a new version of the patch. > Ok will hold off till review till the next patchset... BTW this datasheet's calculations made my eyes bleed so it is quiet likely it has bugs... Thanks, Matt > Andreas > >> >> Yours, >> Linus Walleij > > -- > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND 2/2] pps: fix padding issue with PPS_FETCH for ioctl_compat
Issue is that x86 32-bit aligns to 4-bytes instead of 8-bytes
so this patchset works around the issue and corrects the data
returned in pps_fdata_compat.
Cc: Greg Kroah-Hartman
Acked-by: Rodolfo Giometti
Signed-off-by: Matt Ranostay
---
drivers/pps/pps.c| 110 ++-
include/uapi/linux/pps.h | 19
2 files changed, 98 insertions(+), 31 deletions(-)
diff --git a/drivers/pps/pps.c b/drivers/pps/pps.c
index 452ead5a5e52..6eb0db37dd88 100644
--- a/drivers/pps/pps.c
+++ b/drivers/pps/pps.c
@@ -64,6 +64,43 @@ static int pps_cdev_fasync(int fd, struct file *file, int on)
return fasync_helper(fd, file, on, &pps->async_queue);
}
+static int pps_cdev_pps_fetch(struct pps_device *pps, struct pps_fdata *fdata)
+{
+ unsigned int ev = pps->last_ev;
+ int err = 0;
+
+ /* Manage the timeout */
+ if (fdata->timeout.flags & PPS_TIME_INVALID)
+ err = wait_event_interruptible(pps->queue,
+ ev != pps->last_ev);
+ else {
+ unsigned long ticks;
+
+ dev_dbg(pps->dev, "timeout %lld.%09d\n",
+ (long long) fdata->timeout.sec,
+ fdata->timeout.nsec);
+ ticks = fdata->timeout.sec * HZ;
+ ticks += fdata->timeout.nsec / (NSEC_PER_SEC / HZ);
+
+ if (ticks != 0) {
+ err = wait_event_interruptible_timeout(
+ pps->queue,
+ ev != pps->last_ev,
+ ticks);
+ if (err == 0)
+ return -ETIMEDOUT;
+ }
+ }
+
+ /* Check for pending signals */
+ if (err == -ERESTARTSYS) {
+ dev_dbg(pps->dev, "pending signal caught\n");
+ return -EINTR;
+ }
+
+ return 0;
+}
+
static long pps_cdev_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
{
@@ -144,7 +181,6 @@ static long pps_cdev_ioctl(struct file *file,
case PPS_FETCH: {
struct pps_fdata fdata;
- unsigned int ev;
dev_dbg(pps->dev, "PPS_FETCH\n");
@@ -152,36 +188,9 @@ static long pps_cdev_ioctl(struct file *file,
if (err)
return -EFAULT;
- ev = pps->last_ev;
-
- /* Manage the timeout */
- if (fdata.timeout.flags & PPS_TIME_INVALID)
- err = wait_event_interruptible(pps->queue,
- ev != pps->last_ev);
- else {
- unsigned long ticks;
-
- dev_dbg(pps->dev, "timeout %lld.%09d\n",
- (long long) fdata.timeout.sec,
- fdata.timeout.nsec);
- ticks = fdata.timeout.sec * HZ;
- ticks += fdata.timeout.nsec / (NSEC_PER_SEC / HZ);
-
- if (ticks != 0) {
- err = wait_event_interruptible_timeout(
- pps->queue,
- ev != pps->last_ev,
- ticks);
- if (err == 0)
- return -ETIMEDOUT;
- }
- }
-
- /* Check for pending signals */
- if (err == -ERESTARTSYS) {
- dev_dbg(pps->dev, "pending signal caught\n");
- return -EINTR;
- }
+ err = pps_cdev_pps_fetch(pps, &fdata);
+ if (err)
+ return err;
/* Return the fetched timestamp */
spin_lock_irq(&pps->lock);
@@ -246,8 +255,47 @@ static long pps_cdev_ioctl(struct file *file,
static long pps_cdev_compat_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
{
+ struct pps_device *pps = file->private_data;
+ void __user *uarg = (void __user *) arg;
+
cmd = _IOC(_IOC_DIR(cmd), _IOC_TYPE(cmd), _IOC_NR(cmd), sizeof(void *));
+ if (cmd == PPS_FETCH) {
+ struct pps_fdata_compat compat;
+ struct pps_fdata fdata;
+ int err;
+
+ dev_dbg(pps->dev, "PPS_FETCH\n");
+
+ err = copy_from_user(&compat, uarg, sizeof(struct
pps_fdata_compat));
+ if (err)
+ return -EFAULT;
+
+ memcpy(&fdata.timeout, &compat.timeout,
+ sizeof(struct pps_ktime_compat));
+
+
[PATCH RESEND 1/2] pps: add ioctl_compat function to correct ioctl definitions
ioctl definitions use the pointer size of the architecture which
is fine when userspace and kernel are the same bitsize. This
patchset workarounds an issue with mixed bitsize kernel + userspace
by rewriting the cmd to the kernelspace architecture pointer size.
Cc: Greg Kroah-Hartman
Acked-by: Rodolfo Giometti
Signed-off-by: Matt Ranostay
---
drivers/pps/pps.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/pps/pps.c b/drivers/pps/pps.c
index 2f07cd615665..452ead5a5e52 100644
--- a/drivers/pps/pps.c
+++ b/drivers/pps/pps.c
@@ -242,6 +242,18 @@ static long pps_cdev_ioctl(struct file *file,
return 0;
}
+#ifdef CONFIG_COMPAT
+static long pps_cdev_compat_ioctl(struct file *file,
+ unsigned int cmd, unsigned long arg)
+{
+ cmd = _IOC(_IOC_DIR(cmd), _IOC_TYPE(cmd), _IOC_NR(cmd), sizeof(void *));
+
+ return pps_cdev_ioctl(file, cmd, arg);
+}
+#else
+#define pps_cdev_compat_ioctl NULL
+#endif
+
static int pps_cdev_open(struct inode *inode, struct file *file)
{
struct pps_device *pps = container_of(inode->i_cdev,
@@ -268,6 +280,7 @@ static const struct file_operations pps_cdev_fops = {
.llseek = no_llseek,
.poll = pps_cdev_poll,
.fasync = pps_cdev_fasync,
+ .compat_ioctl = pps_cdev_compat_ioctl,
.unlocked_ioctl = pps_cdev_ioctl,
.open = pps_cdev_open,
.release= pps_cdev_release,
--
2.10.2
[PATCH RESEND 0/2] pps: add ioctl_compat support
This series fixes issues with 32-bit userspace + 64-bit kernel data structures, and along with fixing incorrect ioctl definitions in a ABI stable way. Changes from initial submission: * add Rodolfo's Acked-by to patchsets * add Greg K-H to Cc list, since there isn't a pps tree to merge in changes Matt Ranostay (2): pps: add ioctl_compat function to correct ioctl definitions pps: fix padding issue with PPS_FETCH for ioctl_compat drivers/pps/pps.c| 123 +++ include/uapi/linux/pps.h | 19 2 files changed, 111 insertions(+), 31 deletions(-) -- 2.10.2
[PATCH 2/2] pps: fix padding issue with PPS_FETCH for ioctl_compat
Issue is that x86 32-bit aligns to 4-bytes instead of 8-bytes
so this patchset works around the issue and corrects the data
returned in pps_fdata_compat.
Cc: Rodolfo Giometti
Cc: Moritz Fischer
Cc: George McCollister
Signed-off-by: Matt Ranostay
---
drivers/pps/pps.c| 110 ++-
include/uapi/linux/pps.h | 19
2 files changed, 98 insertions(+), 31 deletions(-)
diff --git a/drivers/pps/pps.c b/drivers/pps/pps.c
index 452ead5a5e52..6eb0db37dd88 100644
--- a/drivers/pps/pps.c
+++ b/drivers/pps/pps.c
@@ -64,6 +64,43 @@ static int pps_cdev_fasync(int fd, struct file *file, int on)
return fasync_helper(fd, file, on, &pps->async_queue);
}
+static int pps_cdev_pps_fetch(struct pps_device *pps, struct pps_fdata *fdata)
+{
+ unsigned int ev = pps->last_ev;
+ int err = 0;
+
+ /* Manage the timeout */
+ if (fdata->timeout.flags & PPS_TIME_INVALID)
+ err = wait_event_interruptible(pps->queue,
+ ev != pps->last_ev);
+ else {
+ unsigned long ticks;
+
+ dev_dbg(pps->dev, "timeout %lld.%09d\n",
+ (long long) fdata->timeout.sec,
+ fdata->timeout.nsec);
+ ticks = fdata->timeout.sec * HZ;
+ ticks += fdata->timeout.nsec / (NSEC_PER_SEC / HZ);
+
+ if (ticks != 0) {
+ err = wait_event_interruptible_timeout(
+ pps->queue,
+ ev != pps->last_ev,
+ ticks);
+ if (err == 0)
+ return -ETIMEDOUT;
+ }
+ }
+
+ /* Check for pending signals */
+ if (err == -ERESTARTSYS) {
+ dev_dbg(pps->dev, "pending signal caught\n");
+ return -EINTR;
+ }
+
+ return 0;
+}
+
static long pps_cdev_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
{
@@ -144,7 +181,6 @@ static long pps_cdev_ioctl(struct file *file,
case PPS_FETCH: {
struct pps_fdata fdata;
- unsigned int ev;
dev_dbg(pps->dev, "PPS_FETCH\n");
@@ -152,36 +188,9 @@ static long pps_cdev_ioctl(struct file *file,
if (err)
return -EFAULT;
- ev = pps->last_ev;
-
- /* Manage the timeout */
- if (fdata.timeout.flags & PPS_TIME_INVALID)
- err = wait_event_interruptible(pps->queue,
- ev != pps->last_ev);
- else {
- unsigned long ticks;
-
- dev_dbg(pps->dev, "timeout %lld.%09d\n",
- (long long) fdata.timeout.sec,
- fdata.timeout.nsec);
- ticks = fdata.timeout.sec * HZ;
- ticks += fdata.timeout.nsec / (NSEC_PER_SEC / HZ);
-
- if (ticks != 0) {
- err = wait_event_interruptible_timeout(
- pps->queue,
- ev != pps->last_ev,
- ticks);
- if (err == 0)
- return -ETIMEDOUT;
- }
- }
-
- /* Check for pending signals */
- if (err == -ERESTARTSYS) {
- dev_dbg(pps->dev, "pending signal caught\n");
- return -EINTR;
- }
+ err = pps_cdev_pps_fetch(pps, &fdata);
+ if (err)
+ return err;
/* Return the fetched timestamp */
spin_lock_irq(&pps->lock);
@@ -246,8 +255,47 @@ static long pps_cdev_ioctl(struct file *file,
static long pps_cdev_compat_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
{
+ struct pps_device *pps = file->private_data;
+ void __user *uarg = (void __user *) arg;
+
cmd = _IOC(_IOC_DIR(cmd), _IOC_TYPE(cmd), _IOC_NR(cmd), sizeof(void *));
+ if (cmd == PPS_FETCH) {
+ struct pps_fdata_compat compat;
+ struct pps_fdata fdata;
+ int err;
+
+ dev_dbg(pps->dev, "PPS_FETCH\n");
+
+ err = copy_from_user(&compat, uarg, sizeof(struct
pps_fdata_compat));
+ if (err)
+ return -EFAULT;
+
+ memcpy(&fdata.timeout, &compat.timeout,
+ sizeof(struct pps_ktime_com
[PATCH 1/2] pps: add ioctl_compat function to correct ioctl definitions
ioctl definitions use the pointer size of the architecture which
is fine when userspace and kernel are the same bitsize. This
patchset workarounds an issue with mixed bitsize kernel + userspace
by rewriting the cmd to the kernelspace architecture pointer size.
Cc: Rodolfo Giometti
Cc: Moritz Fischer
Cc: George McCollister
Signed-off-by: Matt Ranostay
---
drivers/pps/pps.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/pps/pps.c b/drivers/pps/pps.c
index 2f07cd615665..452ead5a5e52 100644
--- a/drivers/pps/pps.c
+++ b/drivers/pps/pps.c
@@ -242,6 +242,18 @@ static long pps_cdev_ioctl(struct file *file,
return 0;
}
+#ifdef CONFIG_COMPAT
+static long pps_cdev_compat_ioctl(struct file *file,
+ unsigned int cmd, unsigned long arg)
+{
+ cmd = _IOC(_IOC_DIR(cmd), _IOC_TYPE(cmd), _IOC_NR(cmd), sizeof(void *));
+
+ return pps_cdev_ioctl(file, cmd, arg);
+}
+#else
+#define pps_cdev_compat_ioctl NULL
+#endif
+
static int pps_cdev_open(struct inode *inode, struct file *file)
{
struct pps_device *pps = container_of(inode->i_cdev,
@@ -268,6 +280,7 @@ static const struct file_operations pps_cdev_fops = {
.llseek = no_llseek,
.poll = pps_cdev_poll,
.fasync = pps_cdev_fasync,
+ .compat_ioctl = pps_cdev_compat_ioctl,
.unlocked_ioctl = pps_cdev_ioctl,
.open = pps_cdev_open,
.release= pps_cdev_release,
--
2.10.2
[PATCH 0/2] pps: add ioctl_compat support
This series fixes issues with 32-bit userspace + 64-bit kernel data structures, and along with fixing incorrect ioctl definitions in a ABI stable way Matt Ranostay (2): pps: add ioctl_compat function to correct ioctl definitions pps: fix padding issue with PPS_FETCH for ioctl_compat drivers/pps/pps.c| 123 +++ include/uapi/linux/pps.h | 19 2 files changed, 111 insertions(+), 31 deletions(-) -- 2.10.2
Re: [PATCH 2/4] iio: chemical: add driver for dsm501/ppd42ns particle sensors
> On Feb 5, 2017, at 08:24, Tomasz Duszynski wrote:
>
> Thanks for review!
>
>> On Sun, Feb 05, 2017 at 04:19:47PM +0100, Peter Meerwald-Stadler wrote:
>>
>>> This patch adds support for dsm501 and ppd42ns particle sensors.
>>
>> quick comments below
>> G
>>> Both sensors work on the same principle. Heater (resistor) heats up air
>>> in sensor chamber which induces upward flow. Particles convect up through
>>> a light beam provided by internal infra-red LED. Light scattered by
>>> particles is picked by photodiode and internal electronics outputs PWM
>>> signal.
>>>
>>> Measuring low time occupancy of the signal during 30s measurement period
>>> particles number in cubic meter can be computed.
>>>
This a SI unit?
Also this maybe could be better off in drivers/iio/light... as much I like to
have other people in drivers/iio/chemical 😀
>>> Signed-off-by: Tomasz Duszynski
>>> ---
>>> drivers/iio/chemical/Kconfig | 10 ++
>>> drivers/iio/chemical/Makefile | 1 +
>>> drivers/iio/chemical/dsm501.c | 231
>>> ++
>>> 3 files changed, 242 insertions(+)
>>> create mode 100644 drivers/iio/chemical/dsm501.c
>>>
>>> diff --git a/drivers/iio/chemical/Kconfig b/drivers/iio/chemical/Kconfig
>>> index cea7f9857a1f..986d612aa77f 100644
>>> --- a/drivers/iio/chemical/Kconfig
>>> +++ b/drivers/iio/chemical/Kconfig
>>> @@ -21,6 +21,16 @@ config ATLAS_PH_SENSOR
>>> To compile this driver as module, choose M here: the
>>> module will be called atlas-ph-sensor.
>>>
>>> +config DSM501
>>> +tristate "Samyoung DSM501 particle sensor"
>>> +depends on GPIOLIB
>>> +help
>>> + Say yes here to build support for the Samyoung DSM501
>>> + particle sensor.
>>> +
>>> + To compile this driver as a module, choose M here: the module
>>> + will be called dsm501.
>>> +
>>> config IAQCORE
>>>tristate "AMS iAQ-Core VOC sensors"
>>>depends on I2C
>>> diff --git a/drivers/iio/chemical/Makefile b/drivers/iio/chemical/Makefile
>>> index b02202b41289..76f50ff8ba7d 100644
>>> --- a/drivers/iio/chemical/Makefile
>>> +++ b/drivers/iio/chemical/Makefile
>>> @@ -4,5 +4,6 @@
>>>
>>> # When adding new entries keep the list in alphabetical order
>>> obj-$(CONFIG_ATLAS_PH_SENSOR)+= atlas-ph-sensor.o
>>> +obj-$(CONFIG_DSM501)+= dsm501.o
>>> obj-$(CONFIG_IAQCORE)+= ams-iaq-core.o
>>> obj-$(CONFIG_VZ89X)+= vz89x.o
>>> diff --git a/drivers/iio/chemical/dsm501.c b/drivers/iio/chemical/dsm501.c
>>> new file mode 100644
>>> index ..013f6b3bfd48
>>> --- /dev/null
>>> +++ b/drivers/iio/chemical/dsm501.c
>>> @@ -0,0 +1,231 @@
>>> +/*
>>> + * Samyoung DSM501 particle sensor driver
>>> + *
>>> + * Copyright (C) 2017 Tomasz Duszynski
>>> + *
>>> + * Datasheets:
>>> + * http://www.samyoungsnc.com/products/3-1%20Specification%20DSM501.pdf
>>> + * http://wiki.timelab.org/images/f/f9/PPD42NS.pdf
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +#define DSM501_DRV_NAME "dsm501"
>>> +#defineDSM501_IRQ_NAME "dsm501_irq"
>>
>> replace tab by space
> Ack.
>>
>>> +
>>> +#define DSM501_DEFAULT_MEASUREMENT_TIME 30 /* seconds */
>>> +
>>> +struct dsm501_data {
>>> +ktime_t ts;
>>> +ktime_t low_time;
>>> +ktime_t meas_time;
>>> +
>>> +int irq;
>>> +struct gpio_desc *gpio;
>>> +
>>> +struct mutex lock;
>>> +
>>> +int (*number_concentration)(struct dsm501_data *data);
>>> +};
>>> +
>>> +/*
>>> + * Series of data points in Fig. 8-3 (Low Ratio vs Particle)
>>> + * can be approximated by following polynomials:
>>> + *
>>> + * p(r) = 0 (undefined) for r < 4
>>> + * p(r) = 2353564.2r - 4373814.7 for 4 <= r < 20
>>> + * p(r) = 4788112.4r - 53581390 for r >= 20
>>> + *
>>> + * Note: Result is in pcs/m3. To convert to pcs/0.01cf multiply
>>> + * by 0.0002831685.
>>
>> is cf needed?
> No. I've put that sidenote so that others looking at figures in
> datahseets won't scratch their heads why units here are pcs/m3 and
> pcs/0.01cf there. Anyway I am happy to drop that part.
>>
>>> + */
>>> +static int dsm501_number_concentartion(struct dsm501_data *data)
>>> +{
>>> +s64 retval = 0, r = div64_s64(ktime_to_ns(data->low_time) * 100,
>>> + ktime_to_ns(data->meas_time));
>>> +
>>> +if (r >= 4 && r < 20)
>>> +retval =
[PATCH] mailmap: Change email to new Konsulko email
Signed-off-by: Matt Ranostay --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index 67dc22ffc9a8..e775f792d436 100644 --- a/.mailmap +++ b/.mailmap @@ -109,6 +109,7 @@ Mauro Carvalho Chehab Mauro Carvalho Chehab Matt Ranostay Matthew Ranostay Matt Ranostay +Matt Ranostay Mayuresh Janorkar Michael Buesch Michel Dänzer -- 2.10.2
Re: [PATCH v3 1/2] devicetree: document new marvell-8xxx and pwrseq-sd8787 options
On Mon, Jan 23, 2017 at 9:04 AM, Rob Herring wrote:
> On Fri, Jan 20, 2017 at 09:50:38PM -0800, Matt Ranostay wrote:
>> Cc: devicet...@vger.kernel.org
>> Signed-off-by: Matt Ranostay
>> ---
>> .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14
>> ++
>> .../devicetree/bindings/net/wireless/marvell-8xxx.txt | 7 ++-
>> 2 files changed, 20 insertions(+), 1 deletion(-)
>> create mode 100644
>> Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>> b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>> new file mode 100644
>> index ..4bb56766982e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>> @@ -0,0 +1,14 @@
>> +* Marvell SD8787 power sequence provider
>> +
>> +Required properties:
>> +- compatible: must be "mmc-pwrseq-sd8787".
>> +- powerdown-gpio: contains a power down GPIO specifier with active state
>> +- reset-gpio: contains a reset GPIO specifier with active state
>
> My comments on the previous v3 still apply.
Ah yikes.. forgot to increment the patchset. And noticed the gpio
isn't gpios... will fixed in "v4"
Thanks,
Matt
>
>> +
>> +Example:
>> +
>> + wifi_pwrseq: wifi_pwrseq {
>> + compatible = "mmc-pwrseq-sd8787";
>> + powerdown-gpio = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
>> + reset-gpio = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
>> + }
[PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip
Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
This can be abstracted to other chipsets if needed in the future.
Cc: Tony Lindgren
Cc: Ulf Hansson
Signed-off-by: Matt Ranostay
---
drivers/mmc/core/Kconfig | 10
drivers/mmc/core/Makefile| 1 +
drivers/mmc/core/pwrseq_sd8787.c | 117 +++
3 files changed, 128 insertions(+)
create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index cdfa8520a4b1..fc1ecdaaa9ca 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -12,6 +12,16 @@ config PWRSEQ_EMMC
This driver can also be built as a module. If so, the module
will be called pwrseq_emmc.
+config PWRSEQ_SD8787
+ tristate "HW reset support for SD8787 BT + Wifi module"
+ depends on OF && (MWIFIEX || BT_MRVL_SDIO)
+ help
+ This selects hardware reset support for the SD8787 BT + Wifi
+ module. By default this option is set to n.
+
+ This driver can also be built as a module. If so, the module
+ will be called pwrseq_sd8787.
+
config PWRSEQ_SIMPLE
tristate "Simple HW reset support for MMC"
default y
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index b2a257dc644f..0f81464fa824 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \
quirks.o slot-gpio.o
mmc_core-$(CONFIG_OF) += pwrseq.o
obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
+obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o
obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o
mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
diff --git a/drivers/mmc/core/pwrseq_sd8787.c b/drivers/mmc/core/pwrseq_sd8787.c
new file mode 100644
index ..1a21e14458d3
--- /dev/null
+++ b/drivers/mmc/core/pwrseq_sd8787.c
@@ -0,0 +1,117 @@
+/*
+ * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT + Wifi chip
+ *
+ * Copyright (C) 2016 Matt Ranostay
+ *
+ * Based on the original work pwrseq_simple.c
+ * Copyright (C) 2014 Linaro Ltd
+ * Author: Ulf Hansson
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "pwrseq.h"
+
+struct mmc_pwrseq_sd8787 {
+ struct mmc_pwrseq pwrseq;
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *pwrdn_gpio;
+};
+
+#define to_pwrseq_sd8787(p) container_of(p, struct mmc_pwrseq_sd8787, pwrseq)
+
+static void mmc_pwrseq_sd8787_pre_power_on(struct mmc_host *host)
+{
+ struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+ gpiod_set_value_cansleep(pwrseq->reset_gpio, 1);
+
+ msleep(300);
+ gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 1);
+}
+
+static void mmc_pwrseq_sd8787_power_off(struct mmc_host *host)
+{
+ struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+ gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 0);
+ gpiod_set_value_cansleep(pwrseq->reset_gpio, 0);
+}
+
+static const struct mmc_pwrseq_ops mmc_pwrseq_sd8787_ops = {
+ .pre_power_on = mmc_pwrseq_sd8787_pre_power_on,
+ .power_off = mmc_pwrseq_sd8787_power_off,
+};
+
+static const struct of_device_id mmc_pwrseq_sd8787_of_match[] = {
+ { .compatible = "mmc-pwrseq-sd8787",},
+ {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, mmc_pwrseq_sd8787_of_match);
+
+static int mmc_pwrseq_sd8787_probe(struct platform_device *pdev)
+{
+ struct mmc_pwrseq_sd8787 *pwrseq;
+ struct device *dev = &pdev->dev;
+
+ pwrseq = devm_kzalloc(dev, sizeof(*pwrseq), GFP_KERNEL);
+ if (!pwrseq)
+ return -ENOMEM;
+
+ pwrseq->pwrdn_gpio = devm_gpiod_get(dev, "powerdown", GPIOD_OUT_LOW);
+ if (IS_ERR(pwrseq->pwrdn_gpio))
+ return PTR_ERR(pwrseq->pwrdn_gpio);
+
+ pwrseq->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+ if (IS_ERR(pwrseq->reset_gpio))
+ return PTR_ERR(pwrseq->reset_gpio);
+
+ pwrseq->pwrseq.dev = dev;
+ pwrseq->pwrseq.ops = &mmc_pwrseq_sd8787_ops;
+ pwrseq->pwrseq.owner = THIS_MODULE;
+ platform_set_dr
[PATCH v3 1/2] devicetree: document new marvell-8xxx and pwrseq-sd8787 options
Cc: devicet...@vger.kernel.org
Signed-off-by: Matt Ranostay
---
.../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 ++
.../devicetree/bindings/net/wireless/marvell-8xxx.txt | 7 ++-
2 files changed, 20 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
new file mode 100644
index ..4bb56766982e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
@@ -0,0 +1,14 @@
+* Marvell SD8787 power sequence provider
+
+Required properties:
+- compatible: must be "mmc-pwrseq-sd8787".
+- powerdown-gpio: contains a power down GPIO specifier with active state
+- reset-gpio: contains a reset GPIO specifier with active state
+
+Example:
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-sd8787";
+ powerdown-gpio = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
+ reset-gpio = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
+ }
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index 980b16df74c3..0854451ff91d 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,4 +1,4 @@
-Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
+Marvell 8787/8897/8997 (sd8787/sd8897/sd8997/pcie8997) SDIO/PCIE devices
--
This node provides properties for controlling the Marvell SDIO/PCIE wireless
device.
@@ -8,6 +8,7 @@ connects the device to the system.
Required properties:
- compatible : should be one of the following:
+ * "marvell,sd8787"
* "marvell,sd8897"
* "marvell,sd8997"
* "pci11ab,2b42"
@@ -34,6 +35,9 @@ Optional properties:
so that the wifi chip can wakeup host platform under certain
condition.
during system resume, the irq will be disabled to make sure
unnecessary interrupt is not received.
+ - vmmc-supply: a phandle of a regulator, supplying VCC to the card
+ - mmc-pwrseq: phandle to the MMC power sequence node. See "mmc-pwrseq-*"
+for documentation of MMC power sequence bindings.
Example:
@@ -46,6 +50,7 @@ so that firmware can wakeup host using this device side pin.
&mmc3 {
status = "okay";
vmmc-supply = <&wlan_en_reg>;
+ mmc-pwrseq = <&wifi_pwrseq>;
bus-width = <4>;
cap-power-off-card;
keep-power-in-suspend;
--
2.10.2
[PATCH v3 0/2] mmc: pwrseq: add support for Marvell SD8787 chip
Changes from v1: * split devictree docs from pwrseq changes * rebase devicetree documents due to filename change * rebase pwrseq patchset Changes from v2: * update device tree bindings to powerdown-gpios and document active state Matt Ranostay (2): devicetree: document new marvell-8xxx and pwrseq-sd8787 options mmc: pwrseq: add support for Marvell SD8787 chip .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 +++ .../bindings/net/wireless/marvell-8xxx.txt | 7 +- drivers/mmc/core/Kconfig | 10 ++ drivers/mmc/core/Makefile | 1 + drivers/mmc/core/pwrseq_sd8787.c | 117 + 5 files changed, 148 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt create mode 100644 drivers/mmc/core/pwrseq_sd8787.c -- 2.10.2
Re: [PATCH v3] iio: light: acpi-als: Properly enable on ASUS Zenbooks
On Thu, Jan 19, 2017 at 11:01 AM, Josef Gajdusek wrote:
> ASUS Zenbooks need several special ACPI calls to enable the ALS peripheral.
> Otherwise, reads just return 0.
>
> Signed-off-by: Josef Gajdusek
> ---
> drivers/iio/light/acpi-als.c | 60
>
> 1 file changed, 60 insertions(+)
>
> diff --git a/drivers/iio/light/acpi-als.c b/drivers/iio/light/acpi-als.c
> index f0b47c5..43417c9 100644
> --- a/drivers/iio/light/acpi-als.c
> +++ b/drivers/iio/light/acpi-als.c
> @@ -30,6 +30,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -39,6 +40,9 @@
> #define ACPI_ALS_DEVICE_NAME "acpi-als"
> #define ACPI_ALS_NOTIFY_ILLUMINANCE0x80
>
> +#define ACPI_ALS_ASUS_TALS "\\_SB.PCI0.LPCB.EC0.TALS"
> +#define ACPI_ALS_ASUS_ALSC "\\_SB.ATKD.ALSC"
Not sure I like these one off defines... this could easily get out of hand.
Also too lazy to pop out the ACPI spec what does TALS and ALSC mean?
> +
> ACPI_MODULE_NAME("acpi-als");
>
> /*
> @@ -170,6 +174,46 @@ static int acpi_als_read_raw(struct iio_dev *indio_dev,
> return IIO_VAL_INT;
> }
>
> +static int acpi_als_quirk_asus_zenbook_add(struct acpi_als *als)
> +{
> + acpi_status status;
> +
> + status = acpi_execute_simple_method(NULL, ACPI_ALS_ASUS_TALS, 1);
> + if (ACPI_FAILURE(status)) {
> + ACPI_EXCEPTION((AE_INFO, status, "Error enabling ALS by %s",
> + ACPI_ALS_ASUS_TALS));
> + return -EIO;
> + }
> + status = acpi_execute_simple_method(NULL, ACPI_ALS_ASUS_ALSC, 1);
> + if (ACPI_FAILURE(status)) {
> + ACPI_EXCEPTION((AE_INFO, status, "Error enabling ALS by %s",
> + ACPI_ALS_ASUS_ALSC));
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +struct quirk_entry {
> + int (*add)(struct acpi_als *als);
Maybe put the defines above in here.
.tals = "\\_SB.PCI0.LPCB.EC0.TALS",
.alsc = ""\\_SB.ATKD.ALSC"
.
> +};
> +
> +static struct quirk_entry acpi_als_quirk_asus_zenbook = {
> + .add = acpi_als_quirk_asus_zenbook_add
> +};
> +
> +static const struct dmi_system_id acpi_als_quirks[] = {
> + {
> + .ident = "ASUSTeK COMPUTER INC. UX",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "UX"),
Really is the DMI_PRODUCT_NAME only two characters? You are likely
going to need another DMI property to match on.
Thanks,
Matt
> + },
> + .driver_data = &acpi_als_quirk_asus_zenbook,
> + },
> + {},
> +};
> +
> static const struct iio_info acpi_als_info = {
> .driver_module = THIS_MODULE,
> .read_raw = acpi_als_read_raw,
> @@ -180,6 +224,9 @@ static int acpi_als_add(struct acpi_device *device)
> struct acpi_als *als;
> struct iio_dev *indio_dev;
> struct iio_buffer *buffer;
> + const struct dmi_system_id *dmiid;
> + struct quirk_entry *quirk;
> + int ret;
>
> indio_dev = devm_iio_device_alloc(&device->dev, sizeof(*als));
> if (!indio_dev)
> @@ -191,6 +238,19 @@ static int acpi_als_add(struct acpi_device *device)
> als->device = device;
> mutex_init(&als->lock);
>
> + dmiid = dmi_first_match(acpi_als_quirks);
> + if (dmiid) {
> + dev_dbg(&device->dev, "Detected quirk for %s\n",
> dmiid->ident);
> + quirk = dmiid->driver_data;
> + ret = quirk->add(als);
> + if (ret) {
> + dev_err(&device->dev,
> + "Executing quirk for %s failed - %d",
> + dmiid->ident, ret);
> + return ret;
> + }
> + }
> +
> indio_dev->name = ACPI_ALS_DEVICE_NAME;
> indio_dev->dev.parent = &device->dev;
> indio_dev->info = &acpi_als_info;
> --
> 2.10.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip
On Sun, Jan 15, 2017 at 6:35 PM, Shawn Lin wrote: > On 2017/1/16 5:41, Matt Ranostay wrote: >> >> On Thu, Jan 12, 2017 at 11:16 PM, Shawn Lin >> wrote: >>> >>> On 2017/1/13 13:29, Matt Ranostay wrote: >>>> >>>> >>>> Allow power sequencing for the Marvell SD8787 Wifi/BT chip. >>>> This can be abstracted to other chipsets if needed in the future. >>>> >>>> Cc: Tony Lindgren >>>> Cc: Ulf Hansson >>>> Signed-off-by: Matt Ranostay >>>> --- >>>> drivers/mmc/core/Kconfig | 10 >>>> drivers/mmc/core/Makefile| 1 + >>>> drivers/mmc/core/pwrseq_sd8787.c | 117 >>>> +++ >>>> 3 files changed, 128 insertions(+) >>>> create mode 100644 drivers/mmc/core/pwrseq_sd8787.c >>>> >>>> diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig >>>> index cdfa8520a4b1..fc1ecdaaa9ca 100644 >>>> --- a/drivers/mmc/core/Kconfig >>>> +++ b/drivers/mmc/core/Kconfig >>>> @@ -12,6 +12,16 @@ config PWRSEQ_EMMC >>>> This driver can also be built as a module. If so, the module >>>> will be called pwrseq_emmc. >>>> >>>> +config PWRSEQ_SD8787 >>>> + tristate "HW reset support for SD8787 BT + Wifi module" >>>> + depends on OF && (MWIFIEX || BT_MRVL_SDIO) >>>> + help >>>> + This selects hardware reset support for the SD8787 BT + Wifi >>>> + module. By default this option is set to n. >>>> + >>>> + This driver can also be built as a module. If so, the module >>>> + will be called pwrseq_sd8787. >>>> + >>> >>> >>> >>> I don't like this way, as we have a chance to list lots >>> configure options here. wifi A,B,C,D...Z, all of them need a >>> new section here if needed? >>> >>> Instead, could you just extent pwrseq_simple.c and add you >>> .compatible = "mmc-pwrseq-sd8787", "mmc-pwrseq-simple"? >> >> >> You mean all the chipset pwrseqs linked into the pwrseq-simple module? > > > What I mean was if you just extent the pwrseq-simple a bit, you could > just add your chipset pwrseqs linked into the pwrseq-simple. But if you > need a different *pattern* of pwrseqs, you should need a new name, for > instance, pwrseq-sdio.c etc... But please don't use the name of > sd8787? So if I use a wifi named ABC but using the same pwrseq pattenr, > should I include your "mmc-pwrseq- sd8787" for that or I need a new > mmc-pwrseq-ABC.c? Ah so pwrseq-sdio.c seems reasonable and having chipsets functions defined in a structure. That could be abstracted out for other chipsets that could needed in the future. - Matt > > >> >> Ulf your thoughts on this? >> >>> >>> >>> >>>> config PWRSEQ_SIMPLE >>>> tristate "Simple HW reset support for MMC" >>>> default y >>>> diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile >>>> index b2a257dc644f..0f81464fa824 100644 >>>> --- a/drivers/mmc/core/Makefile >>>> +++ b/drivers/mmc/core/Makefile >>>> @@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \ >>>>quirks.o slot-gpio.o >>>> mmc_core-$(CONFIG_OF) += pwrseq.o >>>> obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o >>>> +obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o >>>> obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o >>>> mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o >>>> obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o >>>> diff --git a/drivers/mmc/core/pwrseq_sd8787.c >>>> b/drivers/mmc/core/pwrseq_sd8787.c >>>> new file mode 100644 >>>> index ..f4080fe6439e >>>> --- /dev/null >>>> +++ b/drivers/mmc/core/pwrseq_sd8787.c >>>> @@ -0,0 +1,117 @@ >>>> +/* >>>> + * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT + >>>> Wifi >>>> chip >>>> + * >>>> + * Copyright (C) 2016 Matt Ranostay >>>> + * >>>> + * Based on the original work pwrseq_simple.c >>>> + * Copyright (C) 2014 Linaro Ltd >>>> + * Author: Ulf Hansson >>>> + * >>>>
Re: [PATCH] iio: health: max30100: use msleep() for long uncritical delays
On Mon, Jan 16, 2017 at 7:35 AM, Nicholas Mc Guire wrote:
> ulseep_range() uses hrtimers and provides no advantage over msleep()
> for larger delays. Fix up the 35ms delays here to use msleep() and
> reduce the load on the hrtimer subsystem.
Ok makes sense. Also long as it guaranteed to be at least 35 milliseconds.
Reviewed-by: Matt Ranostay
>
> Fixes: commit 4d33615df58b ("iio: light: add MAX30100 oximeter driver
> support")
> Link: http://lkml.org/lkml/2017/1/11/377
> Signed-off-by: Nicholas Mc Guire
> ---
> Problem located with coccinelle script
>
> Patch was compile tested with: x86_64_defconfig + CONFIG_IIO=m +
> CONFIG_MAX30100=m
>
> Patch is aginast 4.10-rc3 (localversion-next is next-20170116)
>
> drivers/iio/health/max30100.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iio/health/max30100.c b/drivers/iio/health/max30100.c
> index 90ab8a2d..9648c69 100644
> --- a/drivers/iio/health/max30100.c
> +++ b/drivers/iio/health/max30100.c
> @@ -378,7 +378,7 @@ static int max30100_get_temp(struct max30100_data *data,
> int *val)
> if (ret)
> return ret;
>
> - usleep_range(35000, 5);
> + msleep(35);
>
> return max30100_read_temp(data, val);
> }
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip
On Thu, Jan 12, 2017 at 11:16 PM, Shawn Lin wrote:
> On 2017/1/13 13:29, Matt Ranostay wrote:
>>
>> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
>> This can be abstracted to other chipsets if needed in the future.
>>
>> Cc: Tony Lindgren
>> Cc: Ulf Hansson
>> Signed-off-by: Matt Ranostay
>> ---
>> drivers/mmc/core/Kconfig | 10
>> drivers/mmc/core/Makefile| 1 +
>> drivers/mmc/core/pwrseq_sd8787.c | 117
>> +++
>> 3 files changed, 128 insertions(+)
>> create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
>>
>> diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
>> index cdfa8520a4b1..fc1ecdaaa9ca 100644
>> --- a/drivers/mmc/core/Kconfig
>> +++ b/drivers/mmc/core/Kconfig
>> @@ -12,6 +12,16 @@ config PWRSEQ_EMMC
>> This driver can also be built as a module. If so, the module
>> will be called pwrseq_emmc.
>>
>> +config PWRSEQ_SD8787
>> + tristate "HW reset support for SD8787 BT + Wifi module"
>> + depends on OF && (MWIFIEX || BT_MRVL_SDIO)
>> + help
>> + This selects hardware reset support for the SD8787 BT + Wifi
>> + module. By default this option is set to n.
>> +
>> + This driver can also be built as a module. If so, the module
>> + will be called pwrseq_sd8787.
>> +
>
>
> I don't like this way, as we have a chance to list lots
> configure options here. wifi A,B,C,D...Z, all of them need a
> new section here if needed?
>
> Instead, could you just extent pwrseq_simple.c and add you
> .compatible = "mmc-pwrseq-sd8787", "mmc-pwrseq-simple"?
You mean all the chipset pwrseqs linked into the pwrseq-simple module?
Ulf your thoughts on this?
>
>
>
>> config PWRSEQ_SIMPLE
>> tristate "Simple HW reset support for MMC"
>> default y
>> diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
>> index b2a257dc644f..0f81464fa824 100644
>> --- a/drivers/mmc/core/Makefile
>> +++ b/drivers/mmc/core/Makefile
>> @@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \
>>quirks.o slot-gpio.o
>> mmc_core-$(CONFIG_OF) += pwrseq.o
>> obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
>> +obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o
>> obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o
>> mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
>> obj-$(CONFIG_MMC_BLOCK) += mmc_block.o
>> diff --git a/drivers/mmc/core/pwrseq_sd8787.c
>> b/drivers/mmc/core/pwrseq_sd8787.c
>> new file mode 100644
>> index ..f4080fe6439e
>> --- /dev/null
>> +++ b/drivers/mmc/core/pwrseq_sd8787.c
>> @@ -0,0 +1,117 @@
>> +/*
>> + * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT + Wifi
>> chip
>> + *
>> + * Copyright (C) 2016 Matt Ranostay
>> + *
>> + * Based on the original work pwrseq_simple.c
>> + * Copyright (C) 2014 Linaro Ltd
>> + * Author: Ulf Hansson
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +
>> +#include "pwrseq.h"
>> +
>> +struct mmc_pwrseq_sd8787 {
>> + struct mmc_pwrseq pwrseq;
>> + struct gpio_desc *reset_gpio;
>> + struct gpio_desc *pwrdn_gpio;
>> +};
>> +
>> +#define to_pwrseq_sd8787(p) container_of(p, struct mmc_pwrseq_sd8787,
>> pwrseq)
>> +
>> +static void mmc_pwrseq_sd8787_pre_power_on(struct mmc_host *host)
>> +{
>> + struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
>> +
>> + gpiod_set_value_cansleep(pwrseq->reset_gpio, 1);
>> +
>> + msleep(300);
>> + gpiod_set_value
[PATCH v3 1/2] devicetree: document new marvell-8xxx and pwrseq-sd8787 options
Cc: devicet...@vger.kernel.org
Signed-off-by: Matt Ranostay
---
.../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 ++
.../devicetree/bindings/net/wireless/marvell-8xxx.txt | 7 ++-
2 files changed, 20 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
new file mode 100644
index ..1b658351629b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
@@ -0,0 +1,14 @@
+* Marvell SD8787 power sequence provider
+
+Required properties:
+- compatible: must be "mmc-pwrseq-sd8787".
+- pwndn-gpio: contains a power down GPIO specifier.
+- reset-gpio: contains a reset GPIO specifier.
+
+Example:
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-sd8787";
+ pwrdn-gpio = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
+ reset-gpio = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
+ }
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index 980b16df74c3..0854451ff91d 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,4 +1,4 @@
-Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
+Marvell 8787/8897/8997 (sd8787/sd8897/sd8997/pcie8997) SDIO/PCIE devices
--
This node provides properties for controlling the Marvell SDIO/PCIE wireless
device.
@@ -8,6 +8,7 @@ connects the device to the system.
Required properties:
- compatible : should be one of the following:
+ * "marvell,sd8787"
* "marvell,sd8897"
* "marvell,sd8997"
* "pci11ab,2b42"
@@ -34,6 +35,9 @@ Optional properties:
so that the wifi chip can wakeup host platform under certain
condition.
during system resume, the irq will be disabled to make sure
unnecessary interrupt is not received.
+ - vmmc-supply: a phandle of a regulator, supplying VCC to the card
+ - mmc-pwrseq: phandle to the MMC power sequence node. See "mmc-pwrseq-*"
+for documentation of MMC power sequence bindings.
Example:
@@ -46,6 +50,7 @@ so that firmware can wakeup host using this device side pin.
&mmc3 {
status = "okay";
vmmc-supply = <&wlan_en_reg>;
+ mmc-pwrseq = <&wifi_pwrseq>;
bus-width = <4>;
cap-power-off-card;
keep-power-in-suspend;
--
2.10.2
[PATCH v3 0/2] mmc: pwrseq: add support for Marvell SD8787 chip
Changes from v1: * split devictree docs from pwrseq changes * rebase devicetree documents due to filename change * rebase pwrseq patchset Changes from v2: * fix rookie mistake missing the main source file and docs Matt Ranostay (2): devicetree: document new marvell-8xxx and pwrseq-sd8787 options mmc: pwrseq: add support for Marvell SD8787 chip .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 +++ .../bindings/net/wireless/marvell-8xxx.txt | 7 +- drivers/mmc/core/Kconfig | 10 ++ drivers/mmc/core/Makefile | 1 + drivers/mmc/core/pwrseq_sd8787.c | 117 + 5 files changed, 148 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt create mode 100644 drivers/mmc/core/pwrseq_sd8787.c -- 2.10.2
[PATCH v3 0/2] mmc: pwrseq: add support for Marvell SD8787 chip
Changes from v1: * split devictree docs from pwrseq changes * rebase devicetree documents due to filename change * rebase pwrseq patchset Changes from v2: * fix rookie mistake missing the main source file and docs Matt Ranostay (2): devicetree: document new marvell-8xxx and pwrseq-sd8787 options mmc: pwrseq: add support for Marvell SD8787 chip .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 +++ .../bindings/net/wireless/marvell-8xxx.txt | 7 +- drivers/mmc/core/Kconfig | 10 ++ drivers/mmc/core/Makefile | 1 + drivers/mmc/core/pwrseq_sd8787.c | 117 + 5 files changed, 148 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt create mode 100644 drivers/mmc/core/pwrseq_sd8787.c -- 2.10.2
[PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip
Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
This can be abstracted to other chipsets if needed in the future.
Cc: Tony Lindgren
Cc: Ulf Hansson
Signed-off-by: Matt Ranostay
---
drivers/mmc/core/Kconfig | 10
drivers/mmc/core/Makefile| 1 +
drivers/mmc/core/pwrseq_sd8787.c | 117 +++
3 files changed, 128 insertions(+)
create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index cdfa8520a4b1..fc1ecdaaa9ca 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -12,6 +12,16 @@ config PWRSEQ_EMMC
This driver can also be built as a module. If so, the module
will be called pwrseq_emmc.
+config PWRSEQ_SD8787
+ tristate "HW reset support for SD8787 BT + Wifi module"
+ depends on OF && (MWIFIEX || BT_MRVL_SDIO)
+ help
+ This selects hardware reset support for the SD8787 BT + Wifi
+ module. By default this option is set to n.
+
+ This driver can also be built as a module. If so, the module
+ will be called pwrseq_sd8787.
+
config PWRSEQ_SIMPLE
tristate "Simple HW reset support for MMC"
default y
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index b2a257dc644f..0f81464fa824 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \
quirks.o slot-gpio.o
mmc_core-$(CONFIG_OF) += pwrseq.o
obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
+obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o
obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o
mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
diff --git a/drivers/mmc/core/pwrseq_sd8787.c b/drivers/mmc/core/pwrseq_sd8787.c
new file mode 100644
index ..f4080fe6439e
--- /dev/null
+++ b/drivers/mmc/core/pwrseq_sd8787.c
@@ -0,0 +1,117 @@
+/*
+ * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT + Wifi chip
+ *
+ * Copyright (C) 2016 Matt Ranostay
+ *
+ * Based on the original work pwrseq_simple.c
+ * Copyright (C) 2014 Linaro Ltd
+ * Author: Ulf Hansson
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "pwrseq.h"
+
+struct mmc_pwrseq_sd8787 {
+ struct mmc_pwrseq pwrseq;
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *pwrdn_gpio;
+};
+
+#define to_pwrseq_sd8787(p) container_of(p, struct mmc_pwrseq_sd8787, pwrseq)
+
+static void mmc_pwrseq_sd8787_pre_power_on(struct mmc_host *host)
+{
+ struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+ gpiod_set_value_cansleep(pwrseq->reset_gpio, 1);
+
+ msleep(300);
+ gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 1);
+}
+
+static void mmc_pwrseq_sd8787_power_off(struct mmc_host *host)
+{
+ struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+ gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 0);
+ gpiod_set_value_cansleep(pwrseq->reset_gpio, 0);
+}
+
+static const struct mmc_pwrseq_ops mmc_pwrseq_sd8787_ops = {
+ .pre_power_on = mmc_pwrseq_sd8787_pre_power_on,
+ .power_off = mmc_pwrseq_sd8787_power_off,
+};
+
+static const struct of_device_id mmc_pwrseq_sd8787_of_match[] = {
+ { .compatible = "mmc-pwrseq-sd8787",},
+ {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, mmc_pwrseq_sd8787_of_match);
+
+static int mmc_pwrseq_sd8787_probe(struct platform_device *pdev)
+{
+ struct mmc_pwrseq_sd8787 *pwrseq;
+ struct device *dev = &pdev->dev;
+
+ pwrseq = devm_kzalloc(dev, sizeof(*pwrseq), GFP_KERNEL);
+ if (!pwrseq)
+ return -ENOMEM;
+
+ pwrseq->pwrdn_gpio = devm_gpiod_get(dev, "pwrdn", GPIOD_OUT_LOW);
+ if (IS_ERR(pwrseq->pwrdn_gpio))
+ return PTR_ERR(pwrseq->pwrdn_gpio);
+
+ pwrseq->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+ if (IS_ERR(pwrseq->reset_gpio))
+ return PTR_ERR(pwrseq->reset_gpio);
+
+ pwrseq->pwrseq.dev = dev;
+ pwrseq->pwrseq.ops = &mmc_pwrseq_sd8787_ops;
+ pwrseq->pwrseq.owner = THIS_MODULE;
+ platform_set_dr
Re: [PATCH v2 2/2] mmc: pwrseq: add support for Marvell SD8787 chip
On Thu, Jan 12, 2017 at 9:22 PM, Matt Ranostay wrote: > Allow power sequencing for the Marvell SD8787 Wifi/BT chip. > This can be abstracted to other chipsets if needed in the future. Er crap seems how the main patch file got dropped out. Resubmitting in a minute... sorry! > > Cc: Tony Lindgren > Cc: Ulf Hansson > Signed-off-by: Matt Ranostay > --- > drivers/mmc/core/Kconfig | 10 ++ > drivers/mmc/core/Makefile | 1 + > 2 files changed, 11 insertions(+) > > diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig > index cdfa8520a4b1..fc1ecdaaa9ca 100644 > --- a/drivers/mmc/core/Kconfig > +++ b/drivers/mmc/core/Kconfig > @@ -12,6 +12,16 @@ config PWRSEQ_EMMC > This driver can also be built as a module. If so, the module > will be called pwrseq_emmc. > > +config PWRSEQ_SD8787 > + tristate "HW reset support for SD8787 BT + Wifi module" > + depends on OF && (MWIFIEX || BT_MRVL_SDIO) > + help > + This selects hardware reset support for the SD8787 BT + Wifi > + module. By default this option is set to n. > + > + This driver can also be built as a module. If so, the module > + will be called pwrseq_sd8787. > + > config PWRSEQ_SIMPLE > tristate "Simple HW reset support for MMC" > default y > diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile > index b2a257dc644f..0f81464fa824 100644 > --- a/drivers/mmc/core/Makefile > +++ b/drivers/mmc/core/Makefile > @@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \ >quirks.o slot-gpio.o > mmc_core-$(CONFIG_OF) += pwrseq.o > obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o > +obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o > obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o > mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o > obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o > -- > 2.10.2 >
[PATCH v2 1/2] devicetree: document vmmc-supply and mmc-pwrseq options
Cc: devicet...@vger.kernel.org
Signed-off-by: Matt Ranostay
---
Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index 980b16df74c3..0854451ff91d 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,4 +1,4 @@
-Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
+Marvell 8787/8897/8997 (sd8787/sd8897/sd8997/pcie8997) SDIO/PCIE devices
--
This node provides properties for controlling the Marvell SDIO/PCIE wireless
device.
@@ -8,6 +8,7 @@ connects the device to the system.
Required properties:
- compatible : should be one of the following:
+ * "marvell,sd8787"
* "marvell,sd8897"
* "marvell,sd8997"
* "pci11ab,2b42"
@@ -34,6 +35,9 @@ Optional properties:
so that the wifi chip can wakeup host platform under certain
condition.
during system resume, the irq will be disabled to make sure
unnecessary interrupt is not received.
+ - vmmc-supply: a phandle of a regulator, supplying VCC to the card
+ - mmc-pwrseq: phandle to the MMC power sequence node. See "mmc-pwrseq-*"
+for documentation of MMC power sequence bindings.
Example:
@@ -46,6 +50,7 @@ so that firmware can wakeup host using this device side pin.
&mmc3 {
status = "okay";
vmmc-supply = <&wlan_en_reg>;
+ mmc-pwrseq = <&wifi_pwrseq>;
bus-width = <4>;
cap-power-off-card;
keep-power-in-suspend;
--
2.10.2
[PATCH v2 2/2] mmc: pwrseq: add support for Marvell SD8787 chip
Allow power sequencing for the Marvell SD8787 Wifi/BT chip. This can be abstracted to other chipsets if needed in the future. Cc: Tony Lindgren Cc: Ulf Hansson Signed-off-by: Matt Ranostay --- drivers/mmc/core/Kconfig | 10 ++ drivers/mmc/core/Makefile | 1 + 2 files changed, 11 insertions(+) diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig index cdfa8520a4b1..fc1ecdaaa9ca 100644 --- a/drivers/mmc/core/Kconfig +++ b/drivers/mmc/core/Kconfig @@ -12,6 +12,16 @@ config PWRSEQ_EMMC This driver can also be built as a module. If so, the module will be called pwrseq_emmc. +config PWRSEQ_SD8787 + tristate "HW reset support for SD8787 BT + Wifi module" + depends on OF && (MWIFIEX || BT_MRVL_SDIO) + help + This selects hardware reset support for the SD8787 BT + Wifi + module. By default this option is set to n. + + This driver can also be built as a module. If so, the module + will be called pwrseq_sd8787. + config PWRSEQ_SIMPLE tristate "Simple HW reset support for MMC" default y diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile index b2a257dc644f..0f81464fa824 100644 --- a/drivers/mmc/core/Makefile +++ b/drivers/mmc/core/Makefile @@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \ quirks.o slot-gpio.o mmc_core-$(CONFIG_OF) += pwrseq.o obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o +obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o -- 2.10.2
[PATCH v2 0/2] mmc: pwrseq: add support for Marvell SD8787 chip
Changes from v1: * split devictree docs from pwrseq changes * rebase devicetree documents due to filename change * rebase pwrseq patchset Matt Ranostay (2): devicetree: document vmmc-supply and mmc-pwrseq options mmc: pwrseq: add support for Marvell SD8787 chip .../devicetree/bindings/net/wireless/marvell-8xxx.txt | 7 ++- drivers/mmc/core/Kconfig | 10 ++ drivers/mmc/core/Makefile | 1 + 3 files changed, 17 insertions(+), 1 deletion(-) -- 2.10.2
Re: [RFC] pps: fixing CONFIG_COMPAT issues
On Fri, Dec 23, 2016 at 7:04 AM, Rodolfo Giometti wrote: > On 12/22/16 21:39, Matt Ranostay wrote: >> >> >> What would be the best way to fix the padding issue without breaking >> userspace applications? Just fixing the alignment with explicit >> padding is of course the clean easy way, but bashing the data in >> compat_ioctl would avoid breakage. > > > Hi Matt, > > I've no experience in this topic... I'm sorry! :( > > Maybe is better waiting for David's advices? In the meantime I'm going to > study the problem a bit better. Just poking to see if anyone has a better solution. Since the long holidays are over :) Thanks, Matt > > Ciao, > > Rodolfo > > -- > > HCE Engineering e-mail: giome...@hce-engineering.com > GNU/Linux Solutions giome...@enneenne.com > Linux Device Driver giome...@linux.it > Embedded Systems phone: +39 349 2432127 > UNIX programming skype: rodolfo.giometti > Cosino Project - the quick prototyping embedded system - www.cosino.io > Freelance ICT Italia - Consulente ICT Italia - www.consulenti-ict.it
[RFC] pps: fixing CONFIG_COMPAT issues
Rodolfo,
I'd like to get some feedback on what would be an upstreamable patch
series for correcting some issues with a 64-bit kernel and using a
32-bit userspace.
First issue is the compat_ioctl has to be sort of hacked since the
IOCTL defines are using pointer sizes in the macro generation (which
works if you don't mix bit sizes of the kernel and userspace) which
should have been just the struct size originally
#define PPS_GETPARAMS _IOR('p', 0xa1, struct pps_kparams *)
#define PPS_SETPARAMS _IOW('p', 0xa2, struct pps_kparams *)
#define PPS_GETCAP _IOR('p', 0xa3, int *)
#define PPS_FETCH _IOWR('p', 0xa4, struct pps_fdata *)
#define PPS_KC_BIND _IOW('p', 0xa5, struct pps_bind_args *)
So basically the workaround we have for that is as follows:
...
static long pps_cdev_compat_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
{
cmd = _IOC(_IOC_DIR(cmd), _IOC_TYPE(cmd), _IOC_NR(cmd), sizeof(void *));
return pps_cdev_ioctl(file, cmd, arg);
}
...
Now the bigger and more ABI breaking issue is with the padding in
struct pps_ktime (which David Woodhouse has a comment in the header).
Which is worked around by __attribute__((aligned, 4)) which of course
breaks userspace for a precompiled 64-bit binary.
So the issue is that on 32-bit x86 aligns at 4-bytes, but 64-bit is at
8-bytes, so the data ferried from the former userspace to the latter
kernel is incorrect. For instance struct pps_kinfo is padded 4 bytes
more in between info and timeout members.
What would be the best way to fix the padding issue without breaking
userspace applications? Just fixing the alignment with explicit
padding is of course the clean easy way, but bashing the data in
compat_ioctl would avoid breakage.
Thanks,
Matt
Re: [PATCH 2/2] iio: adc: hx711: Add IIO driver for AVIA HX711
On Tue, Dec 13, 2016 at 10:02 AM, Andreas Klinger wrote:
> This is the IIO driver for AVIA HX711 ADC which ist mostly used in weighting
> cells.
First off cool that this is finally getting a driver... I'll have to
get the SparkFun breakout and really cheap scale to test :).
>
> The protocol is quite simple and using GPIO's:
> One GPIO is used as clock (SCK) while another GPIO is read (DOUT)
>
> Signed-off-by: Andreas Klinger
> ---
> drivers/iio/adc/Kconfig | 13 +++
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/hx711.c | 269
> +++
> 3 files changed, 283 insertions(+)
> create mode 100644 drivers/iio/adc/hx711.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 932de1f9d1e7..7902b50fcf32 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -205,6 +205,19 @@ config HI8435
> This driver can also be built as a module. If so, the module will be
> called hi8435.
>
> +config HX711
> + tristate "AVIA HX711 ADC for weight cells"
> + depends on GPIOLIB
> + help
> + If you say yes here you get support for AVIA HX711 ADC which is used
> + for weight cells
> +
> + This driver uses two GPIO's, one for setting the clock and the other
> + one for getting the data
> +
> + This driver can also be built as a module. If so, the module will be
> + called hx711.
> +
> config INA2XX_ADC
> tristate "Texas Instruments INA2xx Power Monitors IIO driver"
> depends on I2C && !SENSORS_INA2XX
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index b1aa456e6af3..d46e289900ef 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -21,6 +21,7 @@ obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
> obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
> obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
> obj-$(CONFIG_HI8435) += hi8435.o
> +obj-$(CONFIG_HX711) += hx711.o
> obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
> obj-$(CONFIG_INA2XX_ADC) += ina2xx-adc.o
> obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
> diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
> new file mode 100644
> index ..cbc89e467985
> --- /dev/null
> +++ b/drivers/iio/adc/hx711.c
> @@ -0,0 +1,269 @@
> +/*
> + * HX711: analog to digital converter for weight sensor module
> + *
> + * Copyright (c) Andreas Klinger
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define HX711_GAIN_32 2 /* gain = 32 for channel B */
> +#define HX711_GAIN_64 3 /* gain = 64 for channel A */
> +#define HX711_GAIN_128 1 /* gain = 128 for channel A */
> +
> +
> +struct hx711_data {
> + struct device *dev;
> + dev_t devt;
> + struct gpio_desc*gpiod_sck;
> + struct gpio_desc*gpiod_dout;
> + int gain_pulse;
> + struct mutexlock;
> +};
> +
> +static void hx711_reset(struct hx711_data *hx711_data)
> +{
> + int val;
> + int i;
> +
> + val = gpiod_get_value(hx711_data->gpiod_dout);
could move the val assignment here to the initialization don't think
it will hit 80 chars
> + if (val) {
move "int i" here to avoid compiler initialization warnings
> + dev_warn(hx711_data->dev, "RESET-HX711\n");
> +
> + gpiod_set_value(hx711_data->gpiod_sck, 1);
> + udelay(80);
IIRC this chip has quite a bit of latency thresholds, can't use
usleep_range? Single core embedded systems could have an issue with
continuous polling.
> + gpiod_set_value(hx711_data->gpiod_sck, 0);
> +
> + for (i = 0; i < 1000; i++) {
> + val = gpiod_get_value(hx711_data->gpiod_dout);
> + if (!val)
> + break;
> + /* sleep at least 1 ms*/
> + msleep(1);
> + }
> + }
> +}
> +
> +static int hx711_cycle(struct hx711_data *hx711_data)
> +{
> + int val;
> +
> + /* if preempted for more then 60us while SCK is high:
> +* hx711 is going in reset
> +* ==> measuring is false
> +*/
> + preempt_disable();
> + gpiod_set_value(hx711_data
[PATCH RESEND] tsl2550: fix lux1_input error in low light
ADC channel 0 photodiode detects both infrared + visible light, but ADC channel 1 just detects infrared. However, the latter is a bit more sensitive in that range so complete darkness or low light causes a error condition in which the chan0 - chan1 is negative that results in a -EAGAIN. This patch changes the resulting lux1_input sysfs attribute message from "Resource temporarily unavailable" to a user-grokable lux value of 0. Cc: Arnd Bergmann Cc: Drew Fustini Signed-off-by: Matt Ranostay --- drivers/misc/tsl2550.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/misc/tsl2550.c b/drivers/misc/tsl2550.c index 87a13374fdc0..eb5761067310 100644 --- a/drivers/misc/tsl2550.c +++ b/drivers/misc/tsl2550.c @@ -177,7 +177,7 @@ static int tsl2550_calculate_lux(u8 ch0, u8 ch1) } else lux = 0; else - return -EAGAIN; + return 0; /* LUX range check */ return lux > TSL2550_MAX_LUX ? TSL2550_MAX_LUX : lux; -- 2.7.4
Re: [PATCH] mmc: pwrseq: add support for Marvell SD8787 chip
On Tue, Nov 29, 2016 at 9:13 AM, Javier Martinez Canillas
wrote:
> Hello Matt,
>
> On Thu, Nov 17, 2016 at 10:55 PM, Matt Ranostay
> wrote:
>> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
>> This can be abstracted to other chipsets if needed in the future.
>>
>> Cc: Tony Lindgren
>> Cc: Ulf Hansson
>> Cc: Mark Rutland
>> Cc: Srinivas Kandagatla
>> Signed-off-by: Matt Ranostay
>> ---
>> .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 +++
>> .../bindings/net/wireless/marvell-sd8xxx.txt | 4 +
>> drivers/mmc/core/Kconfig | 10 ++
>> drivers/mmc/core/Makefile | 1 +
>> drivers/mmc/core/pwrseq_sd8787.c | 117
>> +
>> 5 files changed, 146 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>> create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>> b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>
> According Documentation/devicetree/bindings/submitting-patches.txt,
> the DT bindings patches should posted as a separate patch.
Ok will do.
>
>> new file mode 100644
>> index ..1b658351629b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>> @@ -0,0 +1,14 @@
>> +* Marvell SD8787 power sequence provider
>> +
>> +Required properties:
>> +- compatible: must be "mmc-pwrseq-sd8787".
>
> Since this is not a generic binding, the compatible string should have
> a vendor prefix.
>
Makes sense to me.
>> +- pwndn-gpio: contains a power down GPIO specifier.
>> +- reset-gpio: contains a reset GPIO specifier.
>> +
>
> I wonder if we really need a custom power sequence provider for just
> this SDIO WiFI chip though. AFAICT the only missing piece in
> mmc-pwrseq-simple is the power down GPIO property, so maybe
> mmc-pwrseq-simple could be extended instead to have an optional
> powerdown-gpios property and instead in the Marvell SD8787 DT binding
> can be mentioned which mmc-pwrseq-simple properties are required for
> the device.
>
The reason we didn't do that is we need delay between the two
assertions/desertions of GPIOs. It wouldn't seems good practice to
hack the pwrseq-simple for this...
>> +Example:
>> +
>> + wifi_pwrseq: wifi_pwrseq {
>> + compatible = "mmc-pwrseq-sd8787";
>> + pwrdn-gpio = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
>> + reset-gpio = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
>> + }
>> diff --git
>> a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>> b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>
> Does this patch depend on a previous posted series? I don't see this
> file in today's linux-next...
Got renamed to ->
Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt it
seems very recently.
>
>> index c421aba0a5bc..08fd65d35725 100644
>> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>> @@ -32,6 +32,9 @@ Optional properties:
>> so that the wifi chip can wakeup host platform under
>> certain condition.
>> during system resume, the irq will be disabled to make sure
>> unnecessary interrupt is not received.
>> + - vmmc-supply: a phandle of a regulator, supplying VCC to the card
>> + - mmc-pwrseq: phandle to the MMC power sequence node. See "mmc-pwrseq-*"
>> +for documentation of MMC power sequence bindings.
>>
>> Example:
>>
>> @@ -44,6 +47,7 @@ so that firmware can wakeup host using this device side
>> pin.
>> &mmc3 {
>> status = "okay";
>> vmmc-supply = <&wlan_en_reg>;
>> + mmc-pwrseq = <&wifi_pwrseq>;
>> bus-width = <4>;
>> cap-power-off-card;
>> keep-power-in-suspend;
>
> I think this change should be split in a separate patch as well.
>
> Best regards,
> Javier
Re: [PATCH v3] media: i2c-polling: add i2c-polling driver
On Wed, Nov 23, 2016 at 10:31 PM, Matt Ranostay wrote: > On Wed, Nov 23, 2016 at 8:30 AM, Laurent Pinchart > wrote: >> Hi Matt, >> >> Thank you for the patch. >> >> On Tuesday 22 Nov 2016 17:18:40 Matt Ranostay wrote: >>> There are several thermal sensors that only have a low-speed bus >>> interface but output valid video data. This patchset enables support >>> for the AMG88xx "Grid-Eye" sensor family. >>> >>> Cc: Attila Kinali >>> Cc: Marek Vasut >>> Cc: Luca Barbato >>> Signed-off-by: Matt Ranostay >>> --- >>> Changes from v1: >>> * correct i2c_polling_remove() operations >>> * fixed delay calcuation in buffer_queue() >>> * add include linux/slab.h >>> >>> Changes from v2: >>> * fix build error due to typo in include of slab.h >>> >>> drivers/media/i2c/Kconfig | 8 + >>> drivers/media/i2c/Makefile | 1 + >>> drivers/media/i2c/i2c-polling.c | 469 + >> >> Just looking at the driver name I believe a rename is needed. i2c-polling is >> a >> very generic name and would mislead many people into thinking about an I2C >> subsystem core feature instead of a video driver. "video-i2c" is one option, >> I'm open to other ideas. >> >>> 3 files changed, 478 insertions(+) >>> create mode 100644 drivers/media/i2c/i2c-polling.c >>> >>> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig >>> index b31fa6fae009..d840e7be0036 100644 >>> --- a/drivers/media/i2c/Kconfig >>> +++ b/drivers/media/i2c/Kconfig >>> @@ -768,6 +768,14 @@ config VIDEO_M52790 >>> >>>To compile this driver as a module, choose M here: the >>>module will be called m52790. >>> + >>> +config VIDEO_I2C_POLLING >>> + tristate "I2C polling video support" >>> + depends on VIDEO_V4L2 && I2C >>> + select VIDEOBUF2_VMALLOC >>> + ---help--- >>> + Enable the I2C polling video support which supports the following: >>> +* Panasonic AMG88xx Grid-Eye Sensors >>> endmenu >>> >>> menu "Sensors used on soc_camera driver" >>> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile >>> index 92773b2e6225..8182ec9f66b9 100644 >>> --- a/drivers/media/i2c/Makefile >>> +++ b/drivers/media/i2c/Makefile >>> @@ -79,6 +79,7 @@ obj-$(CONFIG_VIDEO_LM3646) += lm3646.o >>> obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o >>> obj-$(CONFIG_VIDEO_AK881X) += ak881x.o >>> obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o >>> +obj-$(CONFIG_VIDEO_I2C_POLLING) += i2c-polling.o >>> obj-$(CONFIG_VIDEO_ML86V7667)+= ml86v7667.o >>> obj-$(CONFIG_VIDEO_OV2659) += ov2659.o >>> obj-$(CONFIG_VIDEO_TC358743) += tc358743.o >>> diff --git a/drivers/media/i2c/i2c-polling.c >>> b/drivers/media/i2c/i2c-polling.c new file mode 100644 >>> index ..46a4eecde2d2 >>> --- /dev/null >>> +++ b/drivers/media/i2c/i2c-polling.c >>> @@ -0,0 +1,469 @@ >>> +/* >>> + * i2c_polling.c - Support for polling I2C video devices >>> + * >>> + * Copyright (C) 2016 Matt Ranostay >>> + * >>> + * Based on the orginal work drivers/media/parport/bw-qcam.c >>> + * >>> + * This program is free software; you can redistribute it and/or modify >>> + * it under the terms of the GNU General Public License as published by >>> + * the Free Software Foundation; either version 2 of the License, or >>> + * (at your option) any later version. >>> + * >>> + * This program is distributed in the hope that it will be useful, >>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >>> + * GNU General Public License for more details. >>> + * >>> + * Supported: >>> + * - Panasonic AMG88xx Grid-Eye Sensors >>> + */ >>> + >>> +#include >>> +#include >> >> I don't think you implement device tree support, is linux/of.h needed ? Or >> maybe you could implement device tree support ;-) >> >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >
Re: [PATCH v3] media: i2c-polling: add i2c-polling driver
On Wed, Nov 23, 2016 at 8:30 AM, Laurent Pinchart
wrote:
> Hi Matt,
>
> Thank you for the patch.
>
> On Tuesday 22 Nov 2016 17:18:40 Matt Ranostay wrote:
>> There are several thermal sensors that only have a low-speed bus
>> interface but output valid video data. This patchset enables support
>> for the AMG88xx "Grid-Eye" sensor family.
>>
>> Cc: Attila Kinali
>> Cc: Marek Vasut
>> Cc: Luca Barbato
>> Signed-off-by: Matt Ranostay
>> ---
>> Changes from v1:
>> * correct i2c_polling_remove() operations
>> * fixed delay calcuation in buffer_queue()
>> * add include linux/slab.h
>>
>> Changes from v2:
>> * fix build error due to typo in include of slab.h
>>
>> drivers/media/i2c/Kconfig | 8 +
>> drivers/media/i2c/Makefile | 1 +
>> drivers/media/i2c/i2c-polling.c | 469 +
>
> Just looking at the driver name I believe a rename is needed. i2c-polling is a
> very generic name and would mislead many people into thinking about an I2C
> subsystem core feature instead of a video driver. "video-i2c" is one option,
> I'm open to other ideas.
>
>> 3 files changed, 478 insertions(+)
>> create mode 100644 drivers/media/i2c/i2c-polling.c
>>
>> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
>> index b31fa6fae009..d840e7be0036 100644
>> --- a/drivers/media/i2c/Kconfig
>> +++ b/drivers/media/i2c/Kconfig
>> @@ -768,6 +768,14 @@ config VIDEO_M52790
>>
>>To compile this driver as a module, choose M here: the
>>module will be called m52790.
>> +
>> +config VIDEO_I2C_POLLING
>> + tristate "I2C polling video support"
>> + depends on VIDEO_V4L2 && I2C
>> + select VIDEOBUF2_VMALLOC
>> + ---help---
>> + Enable the I2C polling video support which supports the following:
>> +* Panasonic AMG88xx Grid-Eye Sensors
>> endmenu
>>
>> menu "Sensors used on soc_camera driver"
>> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
>> index 92773b2e6225..8182ec9f66b9 100644
>> --- a/drivers/media/i2c/Makefile
>> +++ b/drivers/media/i2c/Makefile
>> @@ -79,6 +79,7 @@ obj-$(CONFIG_VIDEO_LM3646) += lm3646.o
>> obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o
>> obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
>> obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
>> +obj-$(CONFIG_VIDEO_I2C_POLLING) += i2c-polling.o
>> obj-$(CONFIG_VIDEO_ML86V7667)+= ml86v7667.o
>> obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
>> obj-$(CONFIG_VIDEO_TC358743) += tc358743.o
>> diff --git a/drivers/media/i2c/i2c-polling.c
>> b/drivers/media/i2c/i2c-polling.c new file mode 100644
>> index ..46a4eecde2d2
>> --- /dev/null
>> +++ b/drivers/media/i2c/i2c-polling.c
>> @@ -0,0 +1,469 @@
>> +/*
>> + * i2c_polling.c - Support for polling I2C video devices
>> + *
>> + * Copyright (C) 2016 Matt Ranostay
>> + *
>> + * Based on the orginal work drivers/media/parport/bw-qcam.c
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * Supported:
>> + * - Panasonic AMG88xx Grid-Eye Sensors
>> + */
>> +
>> +#include
>> +#include
>
> I don't think you implement device tree support, is linux/of.h needed ? Or
> maybe you could implement device tree support ;-)
>
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>
> You don't implement any control, you can drop support for control events as
> well.
>
>> +#include
>
> Please sort includes alphabetically, it makes it easier to locate duplicates.
>
>> +#define I2C_POLLING_DRIVER "i2c-polling"
>> +
>> +struct i2c_polling_chip;
>> +
>> +struct i2c_polling_data {
>> + struct i2c_client *client;
>> + const struct i2c_polling_chip *chip;
>
Re: [PATCH v3] media: i2c-polling: add i2c-polling driver
On Wed, Nov 23, 2016 at 8:30 AM, Laurent Pinchart
wrote:
> Hi Matt,
>
> Thank you for the patch.
>
> On Tuesday 22 Nov 2016 17:18:40 Matt Ranostay wrote:
>> There are several thermal sensors that only have a low-speed bus
>> interface but output valid video data. This patchset enables support
>> for the AMG88xx "Grid-Eye" sensor family.
>>
>> Cc: Attila Kinali
>> Cc: Marek Vasut
>> Cc: Luca Barbato
>> Signed-off-by: Matt Ranostay
>> ---
>> Changes from v1:
>> * correct i2c_polling_remove() operations
>> * fixed delay calcuation in buffer_queue()
>> * add include linux/slab.h
>>
>> Changes from v2:
>> * fix build error due to typo in include of slab.h
>>
>> drivers/media/i2c/Kconfig | 8 +
>> drivers/media/i2c/Makefile | 1 +
>> drivers/media/i2c/i2c-polling.c | 469 +
>
> Just looking at the driver name I believe a rename is needed. i2c-polling is a
> very generic name and would mislead many people into thinking about an I2C
> subsystem core feature instead of a video driver. "video-i2c" is one option,
> I'm open to other ideas.
>
>> 3 files changed, 478 insertions(+)
>> create mode 100644 drivers/media/i2c/i2c-polling.c
>>
>> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
>> index b31fa6fae009..d840e7be0036 100644
>> --- a/drivers/media/i2c/Kconfig
>> +++ b/drivers/media/i2c/Kconfig
>> @@ -768,6 +768,14 @@ config VIDEO_M52790
>>
>>To compile this driver as a module, choose M here: the
>>module will be called m52790.
>> +
>> +config VIDEO_I2C_POLLING
>> + tristate "I2C polling video support"
>> + depends on VIDEO_V4L2 && I2C
>> + select VIDEOBUF2_VMALLOC
>> + ---help---
>> + Enable the I2C polling video support which supports the following:
>> +* Panasonic AMG88xx Grid-Eye Sensors
>> endmenu
>>
>> menu "Sensors used on soc_camera driver"
>> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
>> index 92773b2e6225..8182ec9f66b9 100644
>> --- a/drivers/media/i2c/Makefile
>> +++ b/drivers/media/i2c/Makefile
>> @@ -79,6 +79,7 @@ obj-$(CONFIG_VIDEO_LM3646) += lm3646.o
>> obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o
>> obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
>> obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
>> +obj-$(CONFIG_VIDEO_I2C_POLLING) += i2c-polling.o
>> obj-$(CONFIG_VIDEO_ML86V7667)+= ml86v7667.o
>> obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
>> obj-$(CONFIG_VIDEO_TC358743) += tc358743.o
>> diff --git a/drivers/media/i2c/i2c-polling.c
>> b/drivers/media/i2c/i2c-polling.c new file mode 100644
>> index ..46a4eecde2d2
>> --- /dev/null
>> +++ b/drivers/media/i2c/i2c-polling.c
>> @@ -0,0 +1,469 @@
>> +/*
>> + * i2c_polling.c - Support for polling I2C video devices
>> + *
>> + * Copyright (C) 2016 Matt Ranostay
>> + *
>> + * Based on the orginal work drivers/media/parport/bw-qcam.c
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * Supported:
>> + * - Panasonic AMG88xx Grid-Eye Sensors
>> + */
>> +
>> +#include
>> +#include
>
> I don't think you implement device tree support, is linux/of.h needed ? Or
> maybe you could implement device tree support ;-)
>
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>
> You don't implement any control, you can drop support for control events as
> well.
>
>> +#include
>
> Please sort includes alphabetically, it makes it easier to locate duplicates.
>
>> +#define I2C_POLLING_DRIVER "i2c-polling"
>> +
>> +struct i2c_polling_chip;
>> +
>> +struct i2c_polling_data {
>> + struct i2c_client *client;
>> + const struct i2c_polling_chip *chip;
>
Re: [PATCH v3] media: i2c-polling: add i2c-polling driver
On Wed, Nov 23, 2016 at 8:30 AM, Laurent Pinchart
wrote:
> Hi Matt,
>
> Thank you for the patch.
>
> On Tuesday 22 Nov 2016 17:18:40 Matt Ranostay wrote:
>> There are several thermal sensors that only have a low-speed bus
>> interface but output valid video data. This patchset enables support
>> for the AMG88xx "Grid-Eye" sensor family.
>>
>> Cc: Attila Kinali
>> Cc: Marek Vasut
>> Cc: Luca Barbato
>> Signed-off-by: Matt Ranostay
>> ---
>> Changes from v1:
>> * correct i2c_polling_remove() operations
>> * fixed delay calcuation in buffer_queue()
>> * add include linux/slab.h
>>
>> Changes from v2:
>> * fix build error due to typo in include of slab.h
>>
>> drivers/media/i2c/Kconfig | 8 +
>> drivers/media/i2c/Makefile | 1 +
>> drivers/media/i2c/i2c-polling.c | 469 +
>
> Just looking at the driver name I believe a rename is needed. i2c-polling is a
> very generic name and would mislead many people into thinking about an I2C
> subsystem core feature instead of a video driver. "video-i2c" is one option,
> I'm open to other ideas.
>
>> 3 files changed, 478 insertions(+)
>> create mode 100644 drivers/media/i2c/i2c-polling.c
>>
>> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
>> index b31fa6fae009..d840e7be0036 100644
>> --- a/drivers/media/i2c/Kconfig
>> +++ b/drivers/media/i2c/Kconfig
>> @@ -768,6 +768,14 @@ config VIDEO_M52790
>>
>>To compile this driver as a module, choose M here: the
>>module will be called m52790.
>> +
>> +config VIDEO_I2C_POLLING
>> + tristate "I2C polling video support"
>> + depends on VIDEO_V4L2 && I2C
>> + select VIDEOBUF2_VMALLOC
>> + ---help---
>> + Enable the I2C polling video support which supports the following:
>> +* Panasonic AMG88xx Grid-Eye Sensors
>> endmenu
>>
>> menu "Sensors used on soc_camera driver"
>> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
>> index 92773b2e6225..8182ec9f66b9 100644
>> --- a/drivers/media/i2c/Makefile
>> +++ b/drivers/media/i2c/Makefile
>> @@ -79,6 +79,7 @@ obj-$(CONFIG_VIDEO_LM3646) += lm3646.o
>> obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o
>> obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
>> obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
>> +obj-$(CONFIG_VIDEO_I2C_POLLING) += i2c-polling.o
>> obj-$(CONFIG_VIDEO_ML86V7667)+= ml86v7667.o
>> obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
>> obj-$(CONFIG_VIDEO_TC358743) += tc358743.o
>> diff --git a/drivers/media/i2c/i2c-polling.c
>> b/drivers/media/i2c/i2c-polling.c new file mode 100644
>> index ..46a4eecde2d2
>> --- /dev/null
>> +++ b/drivers/media/i2c/i2c-polling.c
>> @@ -0,0 +1,469 @@
>> +/*
>> + * i2c_polling.c - Support for polling I2C video devices
>> + *
>> + * Copyright (C) 2016 Matt Ranostay
>> + *
>> + * Based on the orginal work drivers/media/parport/bw-qcam.c
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * Supported:
>> + * - Panasonic AMG88xx Grid-Eye Sensors
>> + */
>> +
>> +#include
>> +#include
>
> I don't think you implement device tree support, is linux/of.h needed ? Or
> maybe you could implement device tree support ;-)
>
Indeed.
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>
> You don't implement any control, you can drop support for control events as
> well.
>
>> +#include
>
> Please sort includes alphabetically, it makes it easier to locate duplicates.
>
>> +#define I2C_POLLING_DRIVER "i2c-polling"
>> +
>> +struct i2c_polling_chip;
>> +
>> +struct i2c_polling_data {
>> + struct i2c_client *client;
>> + const struct i2c_pol
[PATCH v3] media: i2c-polling: add i2c-polling driver
There are several thermal sensors that only have a low-speed bus
interface but output valid video data. This patchset enables support
for the AMG88xx "Grid-Eye" sensor family.
Cc: Attila Kinali
Cc: Marek Vasut
Cc: Luca Barbato
Signed-off-by: Matt Ranostay
---
Changes from v1:
* correct i2c_polling_remove() operations
* fixed delay calcuation in buffer_queue()
* add include linux/slab.h
Changes from v2:
* fix build error due to typo in include of slab.h
drivers/media/i2c/Kconfig | 8 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/i2c-polling.c | 469
3 files changed, 478 insertions(+)
create mode 100644 drivers/media/i2c/i2c-polling.c
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index b31fa6fae009..d840e7be0036 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -768,6 +768,14 @@ config VIDEO_M52790
To compile this driver as a module, choose M here: the
module will be called m52790.
+
+config VIDEO_I2C_POLLING
+ tristate "I2C polling video support"
+ depends on VIDEO_V4L2 && I2C
+ select VIDEOBUF2_VMALLOC
+ ---help---
+ Enable the I2C polling video support which supports the following:
+ * Panasonic AMG88xx Grid-Eye Sensors
endmenu
menu "Sensors used on soc_camera driver"
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 92773b2e6225..8182ec9f66b9 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -79,6 +79,7 @@ obj-$(CONFIG_VIDEO_LM3646)+= lm3646.o
obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o
obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
+obj-$(CONFIG_VIDEO_I2C_POLLING)+= i2c-polling.o
obj-$(CONFIG_VIDEO_ML86V7667) += ml86v7667.o
obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
obj-$(CONFIG_VIDEO_TC358743) += tc358743.o
diff --git a/drivers/media/i2c/i2c-polling.c b/drivers/media/i2c/i2c-polling.c
new file mode 100644
index ..46a4eecde2d2
--- /dev/null
+++ b/drivers/media/i2c/i2c-polling.c
@@ -0,0 +1,469 @@
+/*
+ * i2c_polling.c - Support for polling I2C video devices
+ *
+ * Copyright (C) 2016 Matt Ranostay
+ *
+ * Based on the orginal work drivers/media/parport/bw-qcam.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Supported:
+ * - Panasonic AMG88xx Grid-Eye Sensors
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define I2C_POLLING_DRIVER "i2c-polling"
+
+struct i2c_polling_chip;
+
+struct i2c_polling_data {
+ struct i2c_client *client;
+ const struct i2c_polling_chip *chip;
+ struct mutex lock;
+ struct mutex queue_lock;
+ unsigned int last_update;
+
+ struct v4l2_device v4l2_dev;
+ struct video_device vdev;
+ struct vb2_queue vb_vidq;
+};
+
+static struct v4l2_fmtdesc amg88xx_format = {
+ .description = "12-bit Greyscale",
+ .pixelformat = V4L2_PIX_FMT_Y12,
+};
+
+static struct v4l2_frmsize_discrete amg88xx_size = {
+ .width = 8,
+ .height = 8,
+};
+
+struct i2c_polling_chip {
+ /* video dimensions */
+ struct v4l2_fmtdesc *format;
+ struct v4l2_frmsize_discrete *size;
+
+ /* max frames per second */
+ unsigned int max_fps;
+
+ /* pixel buffer size */
+ unsigned int buffer_size;
+
+ /* xfer function */
+ int (*xfer)(struct i2c_polling_data *data, char *buf);
+};
+
+enum {
+ AMG88XX = 0,
+ I2C_POLLING_CHIP_CNT,
+};
+
+static int amg88xx_xfer(struct i2c_polling_data *data, char *buf)
+{
+ struct i2c_client *client = data->client;
+ struct i2c_msg msg[2];
+ u8 reg = 0x80;
+ int ret;
+
+ msg[0].addr = client->addr;
+ msg[0].flags = 0;
+ msg[0].len = 1;
+ msg[0].buf = (char *) ®
+
+ msg[1].addr = client->addr;
+ msg[1].flags = I2C_M_RD;
+ msg[1].len = data->chip->buffer_size;
+ msg[1].buf = (char *) buf;
+
+ ret = i2c_transfer(client->adapter, msg, 2);
+
+ return (ret == 2) ? 0 : -EIO;
+}
+
+static const struct i2c_polling_chip i2c_polling_chips[I2C_POLLING_CHIP_CNT] =
{
+ [AMG88XX] = {
+ .size = &amg88xx_size,
+ .format = &amg88xx_format,
+
[PATCH] mmc: pwrseq: add support for Marvell SD8787 chip
Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
This can be abstracted to other chipsets if needed in the future.
Cc: Tony Lindgren
Cc: Ulf Hansson
Cc: Mark Rutland
Cc: Srinivas Kandagatla
Signed-off-by: Matt Ranostay
---
.../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 +++
.../bindings/net/wireless/marvell-sd8xxx.txt | 4 +
drivers/mmc/core/Kconfig | 10 ++
drivers/mmc/core/Makefile | 1 +
drivers/mmc/core/pwrseq_sd8787.c | 117 +
5 files changed, 146 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
new file mode 100644
index ..1b658351629b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
@@ -0,0 +1,14 @@
+* Marvell SD8787 power sequence provider
+
+Required properties:
+- compatible: must be "mmc-pwrseq-sd8787".
+- pwndn-gpio: contains a power down GPIO specifier.
+- reset-gpio: contains a reset GPIO specifier.
+
+Example:
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-sd8787";
+ pwrdn-gpio = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
+ reset-gpio = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
+ }
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
index c421aba0a5bc..08fd65d35725 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
@@ -32,6 +32,9 @@ Optional properties:
so that the wifi chip can wakeup host platform under certain
condition.
during system resume, the irq will be disabled to make sure
unnecessary interrupt is not received.
+ - vmmc-supply: a phandle of a regulator, supplying VCC to the card
+ - mmc-pwrseq: phandle to the MMC power sequence node. See "mmc-pwrseq-*"
+for documentation of MMC power sequence bindings.
Example:
@@ -44,6 +47,7 @@ so that firmware can wakeup host using this device side pin.
&mmc3 {
status = "okay";
vmmc-supply = <&wlan_en_reg>;
+ mmc-pwrseq = <&wifi_pwrseq>;
bus-width = <4>;
cap-power-off-card;
keep-power-in-suspend;
diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index 250f223aaa80..cf61d676ac06 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -12,6 +12,16 @@ config PWRSEQ_EMMC
This driver can also be built as a module. If so, the module
will be called pwrseq_emmc.
+config PWRSEQ_SD8787
+ tristate "HW reset support for SD8787 BT + Wifi module"
+ depends on OF && (MWIFIEX || BT_MRVL_SDIO)
+ help
+ This selects hardware reset support for the SD8787 BT + Wifi
+ module. By default this option is set to n.
+
+ This driver can also be built as a module. If so, the module
+ will be called pwrseq_sd8787.
+
config PWRSEQ_SIMPLE
tristate "Simple HW reset support for MMC"
default y
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index f007151dfdc6..f1c060e56d4e 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -10,5 +10,6 @@ mmc_core-y:= core.o bus.o host.o \
quirks.o slot-gpio.o
mmc_core-$(CONFIG_OF) += pwrseq.o
obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
+obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o
obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o
mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
diff --git a/drivers/mmc/core/pwrseq_sd8787.c b/drivers/mmc/core/pwrseq_sd8787.c
new file mode 100644
index ..f4080fe6439e
--- /dev/null
+++ b/drivers/mmc/core/pwrseq_sd8787.c
@@ -0,0 +1,117 @@
+/*
+ * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT + Wifi chip
+ *
+ * Copyright (C) 2016 Matt Ranostay
+ *
+ * Based on the original work pwrseq_simple.c
+ * Copyright (C) 2014 Linaro Ltd
+ * Author: Ulf Hansson
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#in
Re: [PATCH v2] media: i2c-polling: add i2c-polling driver
On Mon, Nov 7, 2016 at 11:03 PM, Ozgur wrote:
> Dear Matt;
>
> I think the "inux/slab.h" line is incorrect and I fixed to "linux/slab.h", I
> tested. Success now.
>
> Regards,
>
> ~ Ozgur
>
>>> -#include
>>> +#include
Gah wondering how it built for me. will fix in v3
>
>
> 2016-11-08 9:00 GMT+03:00 Matt Ranostay :
>>
>> There are several thermal sensors that only have a low-speed bus
>> interface but output valid video data. This patchset enables support
>> for the AMG88xx "Grid-Eye" sensor family.
>>
>> Cc: Attila Kinali
>> Cc: Marek Vasut
>> Cc: Luca Barbato
>> Signed-off-by: Matt Ranostay
>> ---
>> Changes from v1:
>> * correct i2c_polling_remove() operations
>> * fixed delay calcuation in buffer_queue()
>> * add include linux/slab.h
>>
>> drivers/media/i2c/Kconfig | 8 +
>> drivers/media/i2c/Makefile | 1 +
>> drivers/media/i2c/i2c-polling.c | 469
>>
>> 3 files changed, 478 insertions(+)
>> create mode 100644 drivers/media/i2c/i2c-polling.c
>>
>> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
>> index 2669b4bad910..6346eeecfaae 100644
>> --- a/drivers/media/i2c/Kconfig
>> +++ b/drivers/media/i2c/Kconfig
>> @@ -768,6 +768,14 @@ config VIDEO_M52790
>>
>> To compile this driver as a module, choose M here: the
>> module will be called m52790.
>> +
>> +config VIDEO_I2C_POLLING
>> + tristate "I2C polling video support"
>> + depends on VIDEO_V4L2 && I2C
>> + select VIDEOBUF2_VMALLOC
>> + ---help---
>> + Enable the I2C polling video support which supports the
>> following:
>> + * Panasonic AMG88xx Grid-Eye Sensors
>> endmenu
>>
>> menu "Sensors used on soc_camera driver"
>> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
>> index 92773b2e6225..8182ec9f66b9 100644
>> --- a/drivers/media/i2c/Makefile
>> +++ b/drivers/media/i2c/Makefile
>> @@ -79,6 +79,7 @@ obj-$(CONFIG_VIDEO_LM3646)+= lm3646.o
>> obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o
>> obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
>> obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
>> +obj-$(CONFIG_VIDEO_I2C_POLLING)+= i2c-polling.o
>> obj-$(CONFIG_VIDEO_ML86V7667) += ml86v7667.o
>> obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
>> obj-$(CONFIG_VIDEO_TC358743) += tc358743.o
>> diff --git a/drivers/media/i2c/i2c-polling.c
>> b/drivers/media/i2c/i2c-polling.c
>> new file mode 100644
>> index ..807f3aa84245
>> --- /dev/null
>> +++ b/drivers/media/i2c/i2c-polling.c
>> @@ -0,0 +1,469 @@
>> +/*
>> + * i2c_polling.c - Support for polling I2C video devices
>> + *
>> + * Copyright (C) 2016 Matt Ranostay
>> + *
>> + * Based on the orginal work drivers/media/parport/bw-qcam.c
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * Supported:
>> + * - Panasonic AMG88xx Grid-Eye Sensors
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define I2C_POLLING_DRIVER "i2c-polling"
>> +
>> +struct i2c_polling_chip;
>> +
>> +struct i2c_polling_data {
>> + struct i2c_client *client;
>> + const struct i2c_polling_chip *chip;
>> + struct mutex lock;
>> + struct mutex queue_lock;
>> + unsigned int last_update;
>> +
>> + struct v4l2_device v4l2_dev;
>> + struct video_device vdev;
>> + struct vb2_queue vb_vidq;
>> +};
>> +
>> +static struct v4l2_fmtdesc amg88xx_format = {
>> + .description = "12-bit Greyscale",
>> + .pixelformat = V4L2
[PATCH v2] media: i2c-polling: add i2c-polling driver
There are several thermal sensors that only have a low-speed bus
interface but output valid video data. This patchset enables support
for the AMG88xx "Grid-Eye" sensor family.
Cc: Attila Kinali
Cc: Marek Vasut
Cc: Luca Barbato
Signed-off-by: Matt Ranostay
---
Changes from v1:
* correct i2c_polling_remove() operations
* fixed delay calcuation in buffer_queue()
* add include linux/slab.h
drivers/media/i2c/Kconfig | 8 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/i2c-polling.c | 469
3 files changed, 478 insertions(+)
create mode 100644 drivers/media/i2c/i2c-polling.c
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 2669b4bad910..6346eeecfaae 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -768,6 +768,14 @@ config VIDEO_M52790
To compile this driver as a module, choose M here: the
module will be called m52790.
+
+config VIDEO_I2C_POLLING
+ tristate "I2C polling video support"
+ depends on VIDEO_V4L2 && I2C
+ select VIDEOBUF2_VMALLOC
+ ---help---
+ Enable the I2C polling video support which supports the following:
+ * Panasonic AMG88xx Grid-Eye Sensors
endmenu
menu "Sensors used on soc_camera driver"
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 92773b2e6225..8182ec9f66b9 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -79,6 +79,7 @@ obj-$(CONFIG_VIDEO_LM3646)+= lm3646.o
obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o
obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
+obj-$(CONFIG_VIDEO_I2C_POLLING)+= i2c-polling.o
obj-$(CONFIG_VIDEO_ML86V7667) += ml86v7667.o
obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
obj-$(CONFIG_VIDEO_TC358743) += tc358743.o
diff --git a/drivers/media/i2c/i2c-polling.c b/drivers/media/i2c/i2c-polling.c
new file mode 100644
index ..807f3aa84245
--- /dev/null
+++ b/drivers/media/i2c/i2c-polling.c
@@ -0,0 +1,469 @@
+/*
+ * i2c_polling.c - Support for polling I2C video devices
+ *
+ * Copyright (C) 2016 Matt Ranostay
+ *
+ * Based on the orginal work drivers/media/parport/bw-qcam.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Supported:
+ * - Panasonic AMG88xx Grid-Eye Sensors
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define I2C_POLLING_DRIVER "i2c-polling"
+
+struct i2c_polling_chip;
+
+struct i2c_polling_data {
+ struct i2c_client *client;
+ const struct i2c_polling_chip *chip;
+ struct mutex lock;
+ struct mutex queue_lock;
+ unsigned int last_update;
+
+ struct v4l2_device v4l2_dev;
+ struct video_device vdev;
+ struct vb2_queue vb_vidq;
+};
+
+static struct v4l2_fmtdesc amg88xx_format = {
+ .description = "12-bit Greyscale",
+ .pixelformat = V4L2_PIX_FMT_Y12,
+};
+
+static struct v4l2_frmsize_discrete amg88xx_size = {
+ .width = 8,
+ .height = 8,
+};
+
+struct i2c_polling_chip {
+ /* video dimensions */
+ struct v4l2_fmtdesc *format;
+ struct v4l2_frmsize_discrete *size;
+
+ /* max frames per second */
+ unsigned int max_fps;
+
+ /* pixel buffer size */
+ unsigned int buffer_size;
+
+ /* xfer function */
+ int (*xfer)(struct i2c_polling_data *data, char *buf);
+};
+
+enum {
+ AMG88XX = 0,
+ I2C_POLLING_CHIP_CNT,
+};
+
+static int amg88xx_xfer(struct i2c_polling_data *data, char *buf)
+{
+ struct i2c_client *client = data->client;
+ struct i2c_msg msg[2];
+ u8 reg = 0x80;
+ int ret;
+
+ msg[0].addr = client->addr;
+ msg[0].flags = 0;
+ msg[0].len = 1;
+ msg[0].buf = (char *) ®
+
+ msg[1].addr = client->addr;
+ msg[1].flags = I2C_M_RD;
+ msg[1].len = data->chip->buffer_size;
+ msg[1].buf = (char *) buf;
+
+ ret = i2c_transfer(client->adapter, msg, 2);
+
+ return (ret == 2) ? 0 : -EIO;
+}
+
+static const struct i2c_polling_chip i2c_polling_chips[I2C_POLLING_CHIP_CNT] =
{
+ [AMG88XX] = {
+ .size = &amg88xx_size,
+ .format = &amg88xx_format,
+ .max_fps= 10,
+ .buffer_size= 128,
+
Re: [PATCH] media: i2c-polling: add i2c-polling driver
On Sun, Nov 6, 2016 at 5:21 PM, Matt Ranostay wrote:
> There are several thermal sensors that only have a low-speed bus
> interface but output valid video data. This patchset enables support
> for the AMG88xx "Grid-Eye" sensor family.
>
> Cc: Attila Kinali
> Cc: Marek Vasut
> Cc: Luca Barbato
> Signed-off-by: Matt Ranostay
> ---
> drivers/media/i2c/Kconfig | 8 +
> drivers/media/i2c/Makefile | 1 +
> drivers/media/i2c/i2c-polling.c | 466
>
> 3 files changed, 475 insertions(+)
> create mode 100644 drivers/media/i2c/i2c-polling.c
>
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 2669b4bad910..6346eeecfaae 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -768,6 +768,14 @@ config VIDEO_M52790
>
> To compile this driver as a module, choose M here: the
> module will be called m52790.
> +
> +config VIDEO_I2C_POLLING
> + tristate "I2C polling video support"
> + depends on VIDEO_V4L2 && I2C
> + select VIDEOBUF2_VMALLOC
> + ---help---
> + Enable the I2C polling video support which supports the following:
> + * Panasonic AMG88xx Grid-Eye Sensors
> endmenu
>
> menu "Sensors used on soc_camera driver"
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index 92773b2e6225..8182ec9f66b9 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -79,6 +79,7 @@ obj-$(CONFIG_VIDEO_LM3646)+= lm3646.o
> obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o
> obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
> obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
> +obj-$(CONFIG_VIDEO_I2C_POLLING)+= i2c-polling.o
> obj-$(CONFIG_VIDEO_ML86V7667) += ml86v7667.o
> obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
> obj-$(CONFIG_VIDEO_TC358743) += tc358743.o
> diff --git a/drivers/media/i2c/i2c-polling.c b/drivers/media/i2c/i2c-polling.c
> new file mode 100644
> index ..753e355b5fa9
> --- /dev/null
> +++ b/drivers/media/i2c/i2c-polling.c
> @@ -0,0 +1,466 @@
> +/*
> + * i2c_polling.c - Support for polling I2C video devices
> + *
> + * Copyright (C) 2016 Matt Ranostay
> + *
> + * Based on the orginal work drivers/media/parport/bw-qcam.c
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Supported:
> + * - Panasonic AMG88xx Grid-Eye Sensors
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define I2C_POLLING_DRIVER "i2c-polling"
> +
> +struct i2c_polling_chip;
> +
> +struct i2c_polling_data {
> + struct i2c_client *client;
> + const struct i2c_polling_chip *chip;
> + struct mutex lock;
> + struct mutex queue_lock;
> + unsigned int last_update;
> +
> + struct v4l2_device v4l2_dev;
> + struct video_device vdev;
> + struct vb2_queue vb_vidq;
> +};
> +
> +static struct v4l2_fmtdesc amg88xx_format = {
> + .description = "12-bit Greyscale",
> + .pixelformat = V4L2_PIX_FMT_Y12,
> +};
> +
> +static struct v4l2_frmsize_discrete amg88xx_size = {
> + .width = 8,
> + .height = 8,
> +};
> +
> +struct i2c_polling_chip {
> + /* video dimensions */
> + struct v4l2_fmtdesc *format;
> + struct v4l2_frmsize_discrete *size;
> +
> + /* max frames per second */
> + unsigned int max_fps;
> +
> + /* pixel buffer size */
> + unsigned int buffer_size;
> +
> + /* xfer function */
> + int (*xfer)(struct i2c_polling_data *data, char *buf);
> +};
> +
> +enum {
> + AMG88XX = 0,
> + I2C_POLLING_CHIP_CNT,
> +};
> +
> +static int amg88xx_xfer(struct i2c_polling_data *data, char *buf)
> +{
> + struct i2c_client *client = data->client;
> + struct i2c_msg msg[2];
> + u8 reg = 0x80;
> + int ret;
> +
> + msg[0].addr = client->addr;
> + msg[0].flags = 0;
&g
[PATCH] media: i2c-polling: add i2c-polling driver
There are several thermal sensors that only have a low-speed bus
interface but output valid video data. This patchset enables support
for the AMG88xx "Grid-Eye" sensor family.
Cc: Attila Kinali
Cc: Marek Vasut
Cc: Luca Barbato
Signed-off-by: Matt Ranostay
---
drivers/media/i2c/Kconfig | 8 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/i2c-polling.c | 466
3 files changed, 475 insertions(+)
create mode 100644 drivers/media/i2c/i2c-polling.c
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 2669b4bad910..6346eeecfaae 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -768,6 +768,14 @@ config VIDEO_M52790
To compile this driver as a module, choose M here: the
module will be called m52790.
+
+config VIDEO_I2C_POLLING
+ tristate "I2C polling video support"
+ depends on VIDEO_V4L2 && I2C
+ select VIDEOBUF2_VMALLOC
+ ---help---
+ Enable the I2C polling video support which supports the following:
+ * Panasonic AMG88xx Grid-Eye Sensors
endmenu
menu "Sensors used on soc_camera driver"
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 92773b2e6225..8182ec9f66b9 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -79,6 +79,7 @@ obj-$(CONFIG_VIDEO_LM3646)+= lm3646.o
obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o
obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
+obj-$(CONFIG_VIDEO_I2C_POLLING)+= i2c-polling.o
obj-$(CONFIG_VIDEO_ML86V7667) += ml86v7667.o
obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
obj-$(CONFIG_VIDEO_TC358743) += tc358743.o
diff --git a/drivers/media/i2c/i2c-polling.c b/drivers/media/i2c/i2c-polling.c
new file mode 100644
index ..753e355b5fa9
--- /dev/null
+++ b/drivers/media/i2c/i2c-polling.c
@@ -0,0 +1,466 @@
+/*
+ * i2c_polling.c - Support for polling I2C video devices
+ *
+ * Copyright (C) 2016 Matt Ranostay
+ *
+ * Based on the orginal work drivers/media/parport/bw-qcam.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Supported:
+ * - Panasonic AMG88xx Grid-Eye Sensors
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define I2C_POLLING_DRIVER "i2c-polling"
+
+struct i2c_polling_chip;
+
+struct i2c_polling_data {
+ struct i2c_client *client;
+ const struct i2c_polling_chip *chip;
+ struct mutex lock;
+ struct mutex queue_lock;
+ unsigned int last_update;
+
+ struct v4l2_device v4l2_dev;
+ struct video_device vdev;
+ struct vb2_queue vb_vidq;
+};
+
+static struct v4l2_fmtdesc amg88xx_format = {
+ .description = "12-bit Greyscale",
+ .pixelformat = V4L2_PIX_FMT_Y12,
+};
+
+static struct v4l2_frmsize_discrete amg88xx_size = {
+ .width = 8,
+ .height = 8,
+};
+
+struct i2c_polling_chip {
+ /* video dimensions */
+ struct v4l2_fmtdesc *format;
+ struct v4l2_frmsize_discrete *size;
+
+ /* max frames per second */
+ unsigned int max_fps;
+
+ /* pixel buffer size */
+ unsigned int buffer_size;
+
+ /* xfer function */
+ int (*xfer)(struct i2c_polling_data *data, char *buf);
+};
+
+enum {
+ AMG88XX = 0,
+ I2C_POLLING_CHIP_CNT,
+};
+
+static int amg88xx_xfer(struct i2c_polling_data *data, char *buf)
+{
+ struct i2c_client *client = data->client;
+ struct i2c_msg msg[2];
+ u8 reg = 0x80;
+ int ret;
+
+ msg[0].addr = client->addr;
+ msg[0].flags = 0;
+ msg[0].len = 1;
+ msg[0].buf = (char *) ®
+
+ msg[1].addr = client->addr;
+ msg[1].flags = I2C_M_RD;
+ msg[1].len = data->chip->buffer_size;
+ msg[1].buf = (char *) buf;
+
+ ret = i2c_transfer(client->adapter, msg, 2);
+
+ return (ret == 2) ? 0 : -EIO;
+}
+
+static const struct i2c_polling_chip i2c_polling_chips[I2C_POLLING_CHIP_CNT] =
{
+ [AMG88XX] = {
+ .size = &amg88xx_size,
+ .format = &amg88xx_format,
+ .max_fps= 10,
+ .buffer_size= 128,
+ .xfer = &amg88xx_xfer,
+ },
+};
+
+static const struct v4l2_file_operations i2c_polling_fops = {
+
Re: [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query
On Fri, Nov 4, 2016 at 1:29 PM, Pavel Machek wrote: > On Fri 2016-11-04 07:58:55, Tony Lindgren wrote: >> * Pavel Machek [161104 00:10]: >> > On Thu 2016-11-03 22:00:56, Matt Ranostay wrote: >> > Do you actually have hardware with more than one bq27xxx? >> >> I can at least see the twl4030 battery/charger features >> being used together with some bq device to monitor the >> battery state. Not sure if that counts as multiple >> instances here though :) > > I have that, too, but that was not what i was asking. > > Matt wanted support for different polling intervals on different > bq27xxx chips. I'd like to know know if he actually has more than one > bq27xxx in his device... > Actually only one bq27xxx chip but in theory we could have more. > Best regards, > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [RFC] v4l2 support for thermopile devices
On Thu, Nov 3, 2016 at 8:11 AM, Luca Barbato wrote: > On 03/11/2016 14:21, Attila Kinali wrote: >> On Wed, 2 Nov 2016 23:10:41 -0700 >> Matt Ranostay wrote: >> >>> >>> So does anyone know of any software that is using V4L2_PIX_FMT_Y12 >>> currently? Want to test my driver but seems there isn't anything that >>> uses that format (ffmpeg, mplayer, etc). >>> >>> Raw data seems correct but would like to visualize it :). Suspect I'll >>> need to write a test case application though >> >> I was pretty sure that MPlayer supports 12bit greyscale, but I cannot >> find where it was handled. You can of course pass it to the MPlayer >> internas as 8bit greyscale, which would be IMGFMT_Y8 or just pass >> it on as 16bit which would be IMGFMT_Y16_LE (LE = little endian). >> >> You can find the internal #defines of the image formats in >> libmpcodecs/img_format.h and can use https://www.fourcc.org/yuv.php >> to decode their meaning. >> >> The equivalent for libav would be libavutil/pixfmt.h >> >> Luca Barbato tells me that adding Y12 support to libav would be easy. >> >> Attila Kinali >> > > So easy that is [done][1], it still needs to be tested/reviewed/polished > though. Cool. Although needs to be processed since it is signed value, and because it it is really just 0C based readings with 0.25C steps.. But will look into that when I get a chance. Anyway did hack in basic support so v4l2grab so I could test the sensor, and seems to work well but needs some colorized processing to be useful of course. Soldering iron about 1 meter from sensor -> http://imgur.com/a/8totG > > [1]:https://github.com/lu-zero/libav/commits/gray12 > > lu
Re: [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query
On Wed, Nov 2, 2016 at 1:22 AM, Pavel Machek wrote: > Hi! > >> >> >> Better then previous one. >> >> >> >> >> >> But my version of bq27xxx_battery.c already contains this: >> >> > >> >> > This is for allowing udev rule to set the properties as well. >> >> > otherwise a kinda crude RUN = " echo value > >> >> > /sys/module/bq27xxx_battery/parameters/poll_interval" is required. >> >> >> >> Any thoughts on this? >> > >> > I'd say echo value > >> > /sys/module/bq27xxx_battery/parameters/poll_interval .. is quite >> > adequate solution...? >> > >> > Alternatively, convince us that something else is useful for everyone, >> > and we can do the right thing (poll more often when battery is nearly >> > empty), automatically... >> >> Ok should have had the patchset set it per device, and not use the >> global poll_interval. Of need to add some logic to see if uses the >> global poll_interval or it's own setting. >> >> There are times where you could have multiple batteries connected to >> multiple fuel gauges, and want to up the polling interval on certain >> ones that are discharging at different rates. >> >> But of course I'll let you guys let me know if this seems useful at all. > > I agree per-device polling would be cleaner. > Ok I'll work something up for RFC. > But unless you have hardware with more than one bq27xxx, I'd avoid the > work... > > Now... its also possible that poll_interval should change itself > (within kernel) to do the right thing. > True but that is state machine territory, but I'll worry about that later... > Best regards, > > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [RFC] v4l2 support for thermopile devices
On Fri, Oct 28, 2016 at 7:59 PM, Matt Ranostay wrote: > On Fri, Oct 28, 2016 at 2:53 PM, Hans Verkuil wrote: >> Hi Matt, >> >> On 28/10/16 22:14, Matt Ranostay wrote: >>> >>> So want to toss a few thoughts on adding support for thermopile >>> devices (could be used for FLIR Lepton as well) that output pixel >>> data. >>> These typically aren't DMA'able devices since they are low speed >>> (partly to limiting the functionality to be in compliance with ITAR) >>> and data is piped over i2c/spi. >>> >>> My question is that there doesn't seem to be an other driver that >>> polls frames off of a device and pushes it to the video buffer, and >>> wanted to be sure that this doesn't currently exist somewhere. >> >> >> Not anymore, but if you go back to kernel 3.6 then you'll find this driver: >> >> drivers/media/video/bw-qcam.c >> >> It was for a grayscale parallel port webcam (which explains why it was >> removed in 3.7 :-) ), and it used polling to get the pixels. > > Yikes parallel port, but I'll take a look at that for some reference :) So does anyone know of any software that is using V4L2_PIX_FMT_Y12 currently? Want to test my driver but seems there isn't anything that uses that format (ffmpeg, mplayer, etc). Raw data seems correct but would like to visualize it :). Suspect I'll need to write a test case application though > >> >>> Also more importantly does the mailing list thinks it belongs in v4l2? >> >> >> I think it fits. It's a sensor, just with a very small resolution and >> infrared >> instead of visible light. >> >>> We already came up the opinion on the IIO list that it doesn't belong >>> in that subsystem since pushing raw pixel data to a buffer is a bit >>> hacky. Also could be generically written with regmap so other devices >>> (namely FLIR Lepton) could be easily supported. >>> >>> Need some input for the video pixel data types, which the device we >>> are using (see datasheet links below) is outputting pixel data in >>> little endian 16-bit of which a 12-bits signed value is used. Does it >>> make sense to do some basic processing on the data since greyscale is >>> going to look weird with temperatures under 0C degrees? Namely a cold >>> object is going to be brighter than the hottest object it could read. >> >> >>> Or should a new V4L2_PIX_FMT_* be defined and processing done in >>> software? >> >> >> I would recommend that. It's no big deal, as long as the new format is >> documented. >> >>> Another issue is how to report the scaling value of 0.25 C >>> for each LSB of the pixels to the respecting recording application. >> >> >> Probably through a read-only control, but I'm not sure. >> >> Regards, >> >> Hans >> >>> >>> Datasheet: >>> http://media.digikey.com/pdf/Data%20Sheets/Panasonic%20Sensors%20PDFs/Grid-EYE_AMG88.pdf >>> Datasheet: >>> https://eewiki.net/download/attachments/13599167/Grid-EYE%20SPECIFICATIONS%28Reference%29.pdf?version=1&modificationDate=1380660426690&api=v2 >>> >>> Thanks, >>> >>> Matt >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-media" in >>> the body of a message to majord...@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >>
Re: [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query
On Mon, Oct 31, 2016 at 2:38 PM, Pavel Machek wrote: > On Mon 2016-10-31 13:22:18, Matt Ranostay wrote: >> On Tue, Oct 25, 2016 at 11:47 AM, Matt Ranostay wrote: >> > On Mon, Oct 24, 2016 at 1:14 PM, Pavel Machek wrote: >> >> On Mon 2016-10-24 12:58:25, Matt Ranostay wrote: >> >>> Pavel + Sebastian this is the patchset that need I some input on :) >> >> >> >> Better then previous one. >> >> >> >> But my version of bq27xxx_battery.c already contains this: >> > >> > This is for allowing udev rule to set the properties as well. >> > otherwise a kinda crude RUN = " echo value > >> > /sys/module/bq27xxx_battery/parameters/poll_interval" is required. >> >> Any thoughts on this? > > I'd say echo value > > /sys/module/bq27xxx_battery/parameters/poll_interval .. is quite > adequate solution...? > > Alternatively, convince us that something else is useful for everyone, > and we can do the right thing (poll more often when battery is nearly > empty), automatically... Ok should have had the patchset set it per device, and not use the global poll_interval. Of need to add some logic to see if uses the global poll_interval or it's own setting. There are times where you could have multiple batteries connected to multiple fuel gauges, and want to up the polling interval on certain ones that are discharging at different rates. But of course I'll let you guys let me know if this seems useful at all. > > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH 1/6] staging: iio: set proper supply name to devm_regulator_get()
On Mon, Oct 31, 2016 at 10:04 AM, Eva Rachel Retuya wrote:
> The name passed to devm_regulator_get() should match the name of the
> supply as specified in the device datasheet. This makes it clear what
> power supply is being referred to in case of presence of other
> regulators.
>
> Currently, the supply name specified on the affected devices is 'vcc'.
> Use lowercase version of the datasheet name to specify the supply
> voltage.
>
Aren't we possibly breaking current device tree definitions that
people may have? We should still check the old name after the new
datasheet name in my opinion.
> Suggested-by: Lars-Peter Clausen
> Signed-off-by: Eva Rachel Retuya
> ---
> drivers/staging/iio/adc/ad7192.c| 2 +-
> drivers/staging/iio/adc/ad7780.c| 2 +-
> drivers/staging/iio/frequency/ad9832.c | 2 +-
> drivers/staging/iio/frequency/ad9834.c | 2 +-
> drivers/staging/iio/impedance-analyzer/ad5933.c | 2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/iio/adc/ad7192.c
> b/drivers/staging/iio/adc/ad7192.c
> index bfa12ce..41fb32d 100644
> --- a/drivers/staging/iio/adc/ad7192.c
> +++ b/drivers/staging/iio/adc/ad7192.c
> @@ -633,7 +633,7 @@ static int ad7192_probe(struct spi_device *spi)
>
> st = iio_priv(indio_dev);
>
> - st->reg = devm_regulator_get(&spi->dev, "vcc");
> + st->reg = devm_regulator_get(&spi->dev, "avdd");
> if (!IS_ERR(st->reg)) {
> ret = regulator_enable(st->reg);
> if (ret)
> diff --git a/drivers/staging/iio/adc/ad7780.c
> b/drivers/staging/iio/adc/ad7780.c
> index c9a0c2a..a88236e 100644
> --- a/drivers/staging/iio/adc/ad7780.c
> +++ b/drivers/staging/iio/adc/ad7780.c
> @@ -173,7 +173,7 @@ static int ad7780_probe(struct spi_device *spi)
>
> ad_sd_init(&st->sd, indio_dev, spi, &ad7780_sigma_delta_info);
>
> - st->reg = devm_regulator_get(&spi->dev, "vcc");
> + st->reg = devm_regulator_get(&spi->dev, "avdd");
> if (!IS_ERR(st->reg)) {
> ret = regulator_enable(st->reg);
> if (ret)
> diff --git a/drivers/staging/iio/frequency/ad9832.c
> b/drivers/staging/iio/frequency/ad9832.c
> index 358400b..744c8ee 100644
> --- a/drivers/staging/iio/frequency/ad9832.c
> +++ b/drivers/staging/iio/frequency/ad9832.c
> @@ -212,7 +212,7 @@ static int ad9832_probe(struct spi_device *spi)
> return -ENODEV;
> }
>
> - reg = devm_regulator_get(&spi->dev, "vcc");
> + reg = devm_regulator_get(&spi->dev, "avdd");
> if (!IS_ERR(reg)) {
> ret = regulator_enable(reg);
> if (ret)
> diff --git a/drivers/staging/iio/frequency/ad9834.c
> b/drivers/staging/iio/frequency/ad9834.c
> index 6366216..ca3cea6 100644
> --- a/drivers/staging/iio/frequency/ad9834.c
> +++ b/drivers/staging/iio/frequency/ad9834.c
> @@ -329,7 +329,7 @@ static int ad9834_probe(struct spi_device *spi)
> return -ENODEV;
> }
>
> - reg = devm_regulator_get(&spi->dev, "vcc");
> + reg = devm_regulator_get(&spi->dev, "avdd");
> if (!IS_ERR(reg)) {
> ret = regulator_enable(reg);
> if (ret)
> diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c
> b/drivers/staging/iio/impedance-analyzer/ad5933.c
> index 5eecf1c..62f61bc 100644
> --- a/drivers/staging/iio/impedance-analyzer/ad5933.c
> +++ b/drivers/staging/iio/impedance-analyzer/ad5933.c
> @@ -723,7 +723,7 @@ static int ad5933_probe(struct i2c_client *client,
> if (!pdata)
> pdata = &ad5933_default_pdata;
>
> - st->reg = devm_regulator_get(&client->dev, "vcc");
> + st->reg = devm_regulator_get(&client->dev, "vdd");
> if (!IS_ERR(st->reg)) {
> ret = regulator_enable(st->reg);
> if (ret)
> --
> 2.7.4
>
Re: [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query
On Tue, Oct 25, 2016 at 11:47 AM, Matt Ranostay wrote:
> On Mon, Oct 24, 2016 at 1:14 PM, Pavel Machek wrote:
>> On Mon 2016-10-24 12:58:25, Matt Ranostay wrote:
>>> Pavel + Sebastian this is the patchset that need I some input on :)
>>
>> Better then previous one.
>>
>> But my version of bq27xxx_battery.c already contains this:
>
> This is for allowing udev rule to set the properties as well.
> otherwise a kinda crude RUN = " echo value >
> /sys/module/bq27xxx_battery/parameters/poll_interval" is required.
Any thoughts on this?
Thanks,
Matt
>
>>
>> static const struct kernel_param_ops param_ops_poll_interval = {
>> .get = param_get_uint,
>> .set = poll_interval_param_set,
>> };
>>
>> ...so it should be possible to set poll interval already.
>>
>> Pavel
>>
>> --
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures)
>> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [RFC] v4l2 support for thermopile devices
On Fri, Oct 28, 2016 at 2:53 PM, Hans Verkuil wrote: > Hi Matt, > > On 28/10/16 22:14, Matt Ranostay wrote: >> >> So want to toss a few thoughts on adding support for thermopile >> devices (could be used for FLIR Lepton as well) that output pixel >> data. >> These typically aren't DMA'able devices since they are low speed >> (partly to limiting the functionality to be in compliance with ITAR) >> and data is piped over i2c/spi. >> >> My question is that there doesn't seem to be an other driver that >> polls frames off of a device and pushes it to the video buffer, and >> wanted to be sure that this doesn't currently exist somewhere. > > > Not anymore, but if you go back to kernel 3.6 then you'll find this driver: > > drivers/media/video/bw-qcam.c > > It was for a grayscale parallel port webcam (which explains why it was > removed in 3.7 :-) ), and it used polling to get the pixels. Yikes parallel port, but I'll take a look at that for some reference :) > >> Also more importantly does the mailing list thinks it belongs in v4l2? > > > I think it fits. It's a sensor, just with a very small resolution and > infrared > instead of visible light. > >> We already came up the opinion on the IIO list that it doesn't belong >> in that subsystem since pushing raw pixel data to a buffer is a bit >> hacky. Also could be generically written with regmap so other devices >> (namely FLIR Lepton) could be easily supported. >> >> Need some input for the video pixel data types, which the device we >> are using (see datasheet links below) is outputting pixel data in >> little endian 16-bit of which a 12-bits signed value is used. Does it >> make sense to do some basic processing on the data since greyscale is >> going to look weird with temperatures under 0C degrees? Namely a cold >> object is going to be brighter than the hottest object it could read. > > >> Or should a new V4L2_PIX_FMT_* be defined and processing done in >> software? > > > I would recommend that. It's no big deal, as long as the new format is > documented. > >> Another issue is how to report the scaling value of 0.25 C >> for each LSB of the pixels to the respecting recording application. > > > Probably through a read-only control, but I'm not sure. > > Regards, > > Hans > >> >> Datasheet: >> http://media.digikey.com/pdf/Data%20Sheets/Panasonic%20Sensors%20PDFs/Grid-EYE_AMG88.pdf >> Datasheet: >> https://eewiki.net/download/attachments/13599167/Grid-EYE%20SPECIFICATIONS%28Reference%29.pdf?version=1&modificationDate=1380660426690&api=v2 >> >> Thanks, >> >> Matt >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-media" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >
Re: [RFC] v4l2 support for thermopile devices
On Fri, Oct 28, 2016 at 1:30 PM, Devin Heitmueller wrote: > Hi Matt, > >> Need some input for the video pixel data types, which the device we >> are using (see datasheet links below) is outputting pixel data in >> little endian 16-bit of which a 12-bits signed value is used. Does it >> make sense to do some basic processing on the data since greyscale is >> going to look weird with temperatures under 0C degrees? Namely a cold >> object is going to be brighter than the hottest object it could read. >> Or should a new V4L2_PIX_FMT_* be defined and processing done in >> software? Another issue is how to report the scaling value of 0.25 C >> for each LSB of the pixels to the respecting recording application. > > Regarding the format for the pixel data: I did some research into > this when doing some driver work for the Seek Thermal (a product > similar to the FLIR Lepton). While it would be nice to be able to use > an existing application like VLC or gStreamer to just take the video > and capture from the V4L2 interface with no additional userland code, > the reality is that how you colorize the data is going to be highly > user specific (e.g. what thermal ranges to show with what colors, > etc). If your goal is really to do a V4L2 driver which returns the > raw data, then you're probably best returning it in the native > greyscale format (whether that be an existing V4L2 PIX_FMT or a new > one needs to be defined), and then in software you can figure out how > to colorize it. > Good point I was leaning to having userspace do it. But didn't think of the color mapping part though so even more reason. > Just my opinion though > > Devin > > -- > Devin J. Heitmueller - Kernel Labs > http://www.kernellabs.com
Re: [RFC] v4l2 support for thermopile devices
On Fri, Oct 28, 2016 at 1:40 PM, Marek Vasut wrote: > On 10/28/2016 10:30 PM, Devin Heitmueller wrote: >> Hi Matt, >> >>> Need some input for the video pixel data types, which the device we >>> are using (see datasheet links below) is outputting pixel data in >>> little endian 16-bit of which a 12-bits signed value is used. Does it >>> make sense to do some basic processing on the data since greyscale is >>> going to look weird with temperatures under 0C degrees? Namely a cold >>> object is going to be brighter than the hottest object it could read. >>> Or should a new V4L2_PIX_FMT_* be defined and processing done in >>> software? Another issue is how to report the scaling value of 0.25 C >>> for each LSB of the pixels to the respecting recording application. >> >> Regarding the format for the pixel data: I did some research into >> this when doing some driver work for the Seek Thermal (a product >> similar to the FLIR Lepton). While it would be nice to be able to use >> an existing application like VLC or gStreamer to just take the video >> and capture from the V4L2 interface with no additional userland code, >> the reality is that how you colorize the data is going to be highly >> user specific (e.g. what thermal ranges to show with what colors, >> etc). If your goal is really to do a V4L2 driver which returns the >> raw data, then you're probably best returning it in the native >> greyscale format (whether that be an existing V4L2 PIX_FMT or a new >> one needs to be defined), and then in software you can figure out how >> to colorize it. > > All true, I also did my share of poking into SEEK Thermal USB and it is > an excellent candidate for a V4L2 driver, that one. But I think this > device here is producing much smaller images, something like 8x8 pixels. Yes this is only 64 pixel (8x8 grid) but it is video still. Does have some major pluses over a FLIR camera though, mainly power usage is really low, and cost is lower (although that reason is decreasing everyday). > > -- > Best regards, > Marek Vasut
[RFC] v4l2 support for thermopile devices
So want to toss a few thoughts on adding support for thermopile devices (could be used for FLIR Lepton as well) that output pixel data. These typically aren't DMA'able devices since they are low speed (partly to limiting the functionality to be in compliance with ITAR) and data is piped over i2c/spi. My question is that there doesn't seem to be an other driver that polls frames off of a device and pushes it to the video buffer, and wanted to be sure that this doesn't currently exist somewhere. Also more importantly does the mailing list thinks it belongs in v4l2? We already came up the opinion on the IIO list that it doesn't belong in that subsystem since pushing raw pixel data to a buffer is a bit hacky. Also could be generically written with regmap so other devices (namely FLIR Lepton) could be easily supported. Need some input for the video pixel data types, which the device we are using (see datasheet links below) is outputting pixel data in little endian 16-bit of which a 12-bits signed value is used. Does it make sense to do some basic processing on the data since greyscale is going to look weird with temperatures under 0C degrees? Namely a cold object is going to be brighter than the hottest object it could read. Or should a new V4L2_PIX_FMT_* be defined and processing done in software? Another issue is how to report the scaling value of 0.25 C for each LSB of the pixels to the respecting recording application. Datasheet: http://media.digikey.com/pdf/Data%20Sheets/Panasonic%20Sensors%20PDFs/Grid-EYE_AMG88.pdf Datasheet: https://eewiki.net/download/attachments/13599167/Grid-EYE%20SPECIFICATIONS%28Reference%29.pdf?version=1&modificationDate=1380660426690&api=v2 Thanks, Matt
Re: [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query
On Mon, Oct 24, 2016 at 1:14 PM, Pavel Machek wrote:
> On Mon 2016-10-24 12:58:25, Matt Ranostay wrote:
>> Pavel + Sebastian this is the patchset that need I some input on :)
>
> Better then previous one.
>
> But my version of bq27xxx_battery.c already contains this:
This is for allowing udev rule to set the properties as well.
otherwise a kinda crude RUN = " echo value >
/sys/module/bq27xxx_battery/parameters/poll_interval" is required.
>
> static const struct kernel_param_ops param_ops_poll_interval = {
> .get = param_get_uint,
> .set = poll_interval_param_set,
> };
>
> ...so it should be possible to set poll interval already.
>
> Pavel
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query
Pavel + Sebastian this is the patchset that need I some input on :)
Thanks,
Matt
On Wed, Sep 28, 2016 at 12:55 PM, Matt Ranostay wrote:
> Add POWER_SUPPLY_PROP_POLL_INTERVAL property to query and set the
> polling interval of the fuel gauge.
>
> Cc: Sebastian Reichel
> Cc: Tony Lindgren Signed-off-by: Matt Ranostay
> ---
> drivers/power/supply/bq27xxx_battery.c | 40
> ++
> 1 file changed, 40 insertions(+)
>
> diff --git a/drivers/power/supply/bq27xxx_battery.c
> b/drivers/power/supply/bq27xxx_battery.c
> index 3b0dbc689d72..d18802ca3327 100644
> --- a/drivers/power/supply/bq27xxx_battery.c
> +++ b/drivers/power/supply/bq27xxx_battery.c
> @@ -262,6 +262,7 @@ static enum power_supply_property bq27000_battery_props[]
> = {
> POWER_SUPPLY_PROP_POWER_AVG,
> POWER_SUPPLY_PROP_HEALTH,
> POWER_SUPPLY_PROP_MANUFACTURER,
> + POWER_SUPPLY_PROP_POLL_INTERVAL,
> };
>
> static enum power_supply_property bq27010_battery_props[] = {
> @@ -282,6 +283,7 @@ static enum power_supply_property bq27010_battery_props[]
> = {
> POWER_SUPPLY_PROP_CYCLE_COUNT,
> POWER_SUPPLY_PROP_HEALTH,
> POWER_SUPPLY_PROP_MANUFACTURER,
> + POWER_SUPPLY_PROP_POLL_INTERVAL,
> };
>
> static enum power_supply_property bq27500_battery_props[] = {
> @@ -300,6 +302,7 @@ static enum power_supply_property bq27500_battery_props[]
> = {
> POWER_SUPPLY_PROP_CYCLE_COUNT,
> POWER_SUPPLY_PROP_HEALTH,
> POWER_SUPPLY_PROP_MANUFACTURER,
> + POWER_SUPPLY_PROP_POLL_INTERVAL,
> };
>
> static enum power_supply_property bq27530_battery_props[] = {
> @@ -318,6 +321,7 @@ static enum power_supply_property bq27530_battery_props[]
> = {
> POWER_SUPPLY_PROP_HEALTH,
> POWER_SUPPLY_PROP_CYCLE_COUNT,
> POWER_SUPPLY_PROP_MANUFACTURER,
> + POWER_SUPPLY_PROP_POLL_INTERVAL,
> };
>
> static enum power_supply_property bq27541_battery_props[] = {
> @@ -337,6 +341,7 @@ static enum power_supply_property bq27541_battery_props[]
> = {
> POWER_SUPPLY_PROP_POWER_AVG,
> POWER_SUPPLY_PROP_HEALTH,
> POWER_SUPPLY_PROP_MANUFACTURER,
> + POWER_SUPPLY_PROP_POLL_INTERVAL,
> };
>
> static enum power_supply_property bq27545_battery_props[] = {
> @@ -355,6 +360,7 @@ static enum power_supply_property bq27545_battery_props[]
> = {
> POWER_SUPPLY_PROP_CYCLE_COUNT,
> POWER_SUPPLY_PROP_POWER_AVG,
> POWER_SUPPLY_PROP_MANUFACTURER,
> + POWER_SUPPLY_PROP_POLL_INTERVAL,
> };
>
> static enum power_supply_property bq27421_battery_props[] = {
> @@ -370,6 +376,7 @@ static enum power_supply_property bq27421_battery_props[]
> = {
> POWER_SUPPLY_PROP_CHARGE_NOW,
> POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
> POWER_SUPPLY_PROP_MANUFACTURER,
> + POWER_SUPPLY_PROP_POLL_INTERVAL,
> };
>
> #define BQ27XXX_PROP(_id, _prop) \
> @@ -955,6 +962,9 @@ static int bq27xxx_battery_get_property(struct
> power_supply *psy,
> case POWER_SUPPLY_PROP_MANUFACTURER:
> val->strval = BQ27XXX_MANUFACTURER;
> break;
> + case POWER_SUPPLY_PROP_POLL_INTERVAL:
> + val->intval = poll_interval;
> + break;
> default:
> return -EINVAL;
> }
> @@ -962,6 +972,34 @@ static int bq27xxx_battery_get_property(struct
> power_supply *psy,
> return ret;
> }
>
> +static int bq27xxx_battery_set_property(struct power_supply *psy,
> + enum power_supply_property psp,
> + const union power_supply_propval *val)
> +{
> + struct bq27xxx_device_info *di = power_supply_get_drvdata(psy);
> +
> + if (psp != POWER_SUPPLY_PROP_POLL_INTERVAL)
> + return -EINVAL;
> +
> + if (poll_interval == val->intval)
> + return 0;
> +
> + poll_interval = val->intval;
> + cancel_delayed_work_sync(&di->work);
> + schedule_delayed_work(&di->work, 0);
> +
> + return 0;
> +}
> +
> +static int bq27xxx_property_is_writeable(struct power_supply *psy,
> +enum power_supply_property psp)
> +{
> + if (psp == POWER_SUPPLY_PROP_POLL_INTERVAL)
> + return 1;
> +
> + return 0;
> +}
> +
> static void bq27xxx_external_power_changed(struct power_supply *psy)
> {
> struct bq27xxx_device_info *di = power_supply_get_drvdata(psy);
> @@ -988,6 +1026,8 @@ int bq27xxx_battery_setup(struct bq27xxx_device_
Re: [PATCH 1/2] power: bq27xxx_battery: add configurable poll_interval by sysfs
On Mon, Oct 24, 2016 at 12:51 PM, Pavel Machek wrote:
> On Sun 2016-10-23 20:08:22, Matt Ranostay wrote:
>> On Fri, Oct 7, 2016 at 11:49 AM, Pavel Machek wrote:
>> > On Fri 2016-09-16 20:42:54, Matt Ranostay wrote:
>> >> Allow the poll_interval to be runtime configurable via an sysfs entry.
>> >> This is needed for udev control of the poll interval.
>> >>
>> >> Signed-off-by: Matt Ranostay
>> >
>> > working mail address would be nice here.
>> >
>> > sysfs files should be documented.
>> >
>>
>> Ok can do in next revision
>>
>> > Also... what is it good for?
>> >
>> > Do you have a device that needs non-standard interval?
>>
>> Basically we need to have the ability to dynamically change the
>> intervals. So closer to a battery drain we need to up the reporting
>> intervals.
>
> Umm, there seems to be mechanism there to change that already...?
>
Ah right. Commenting on the wrong patchset oops :).
> static const struct kernel_param_ops param_ops_poll_interval = {
> .get = param_get_uint,
> .set = poll_interval_param_set,
> };
>
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH 1/2] power: bq27xxx_battery: add configurable poll_interval by sysfs
On Fri, Oct 7, 2016 at 11:49 AM, Pavel Machek wrote:
> On Fri 2016-09-16 20:42:54, Matt Ranostay wrote:
>> Allow the poll_interval to be runtime configurable via an sysfs entry.
>> This is needed for udev control of the poll interval.
>>
>> Signed-off-by: Matt Ranostay
>
> working mail address would be nice here.
>
> sysfs files should be documented.
>
Ok can do in next revision
> Also... what is it good for?
>
> Do you have a device that needs non-standard interval?
Basically we need to have the ability to dynamically change the
intervals. So closer to a battery drain we need to up the reporting
intervals.
Thanks,
Matt
> Pavel
>
>> ---
>> drivers/power/supply/bq27xxx_battery.c | 48
>> +-
>> 1 file changed, 47 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/power/supply/bq27xxx_battery.c
>> b/drivers/power/supply/bq27xxx_battery.c
>> index 3f57dd54803a..955424e10ae2 100644
>> --- a/drivers/power/supply/bq27xxx_battery.c
>> +++ b/drivers/power/supply/bq27xxx_battery.c
>> @@ -395,6 +395,36 @@ module_param(poll_interval, uint, 0644);
>> MODULE_PARM_DESC(poll_interval,
>>"battery poll interval in seconds - 0 disables polling");
>>
>> +
>> +static ssize_t show_poll_interval(struct device *dev,
>> + struct device_attribute *attr, char *buf)
>> +{
>> + return sprintf(buf, "%d\n", poll_interval);
>> +}
>> +
>> +static ssize_t store_poll_interval(struct device *dev,
>> +struct device_attribute *attr,
>> +const char *buf, size_t size)
>> +{
>> + struct bq27xxx_device_info *di = dev_get_drvdata(dev);
>> + int tmp = poll_interval;
>> +
>> + if (sscanf(buf, "%d\n", &poll_interval) != 1)
>> + return -EINVAL;
>> +
>> + if (poll_interval < 0)
>> + return -EINVAL;
>> +
>> + if (tmp != poll_interval) {
>> + cancel_delayed_work_sync(&di->work);
>> + schedule_delayed_work(&di->work, 0);
>> + }
>> +
>> + return size;
>> +}
>> +
>> +static DEVICE_ATTR(poll_interval, 0644, show_poll_interval,
>> store_poll_interval);
>> +
>> /*
>> * Common code for BQ27xxx devices
>> */
>> @@ -946,6 +976,7 @@ int bq27xxx_battery_setup(struct bq27xxx_device_info *di)
>> {
>> struct power_supply_desc *psy_desc;
>> struct power_supply_config psy_cfg = { .drv_data = di, };
>> + int ret;
>>
>> INIT_DELAYED_WORK(&di->work, bq27xxx_battery_poll);
>> mutex_init(&di->lock);
>> @@ -961,11 +992,19 @@ int bq27xxx_battery_setup(struct bq27xxx_device_info
>> *di)
>> psy_desc->num_properties = bq27xxx_battery_props[di->chip].size;
>> psy_desc->get_property = bq27xxx_battery_get_property;
>> psy_desc->external_power_changed = bq27xxx_external_power_changed;
>> + dev_set_drvdata(di->dev, di);
>> +
>> + ret = sysfs_create_file(&di->dev->kobj, &dev_attr_poll_interval.attr);
>> + if (ret) {
>> + dev_err(di->dev, "failed to register poll_interval sysfs
>> entry");
>> + return ret;
>> + }
>>
>> di->bat = power_supply_register_no_ws(di->dev, psy_desc, &psy_cfg);
>> if (IS_ERR(di->bat)) {
>> dev_err(di->dev, "failed to register battery\n");
>> - return PTR_ERR(di->bat);
>> + ret = PTR_ERR(di->bat);
>> + goto err_out;
>> }
>>
>> dev_info(di->dev, "support ver. %s enabled\n", DRIVER_VERSION);
>> @@ -973,6 +1012,11 @@ int bq27xxx_battery_setup(struct bq27xxx_device_info
>> *di)
>> bq27xxx_battery_update(di);
>>
>> return 0;
>> +
>> +err_out:
>> + sysfs_remove_file(&di->dev->kobj, &dev_attr_poll_interval.attr);
>> +
>> + return ret;
>> }
>> EXPORT_SYMBOL_GPL(bq27xxx_battery_setup);
>>
>> @@ -988,6 +1032,8 @@ void bq27xxx_battery_teardown(struct
>> bq27xxx_device_info *di)
>>
>> cancel_delayed_work_sync(&di->work);
>>
>> + sysfs_remove_file(&di->dev->kobj, &dev_attr_poll_interval.attr);
>> +
>> power_supply_unregister(di->bat);
>>
>> mutex_destroy(&di->lock);
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH] leds: leds-pca963x: workaround group blink scaling issue
On Fri, Oct 14, 2016 at 7:20 AM, Tony Lindgren wrote: > * Jacek Anaszewski [161013 23:37]: >> On 10/13/2016 04:20 PM, Matt Ranostay wrote: >> > On Thu, Oct 13, 2016 at 4:05 PM, Jacek Anaszewski >> > wrote: >> > > Why DT property? Is it somehow dependent on the board configuration? >> > > How this period-scale value is calculated? Is it inferred empirically? >> > > >> > >> > We empirically discovered and verified this with an logic analyzer on >> > multiple batches of this part. >> > Reason for the DT entry is we aren't 100% sure that it is always going >> > to be the same with different board revs. >> > >> > Could be that parts clock acts differently with supply voltage. This >> > has been calculated by setting it an expected value, and measuring the >> > actual result with the logic analyzer. >> >> I'd like to have DT maintainer's ack for this. >> >> Cc Rob and Mark. > > How about do this based on the compatible property instead? If there > are multiple manufacturers for this part and only a certain > parts have this issue we should have multiple compatible properties. > I could only find that NXP as the manufacturer of that part. It is possible since the clock is internal to the chipset that the vdd of 2.5V is doing something undefined. > Then if it turns out all of them need this scaling there's no need > to update the binding. Understandable. > > Regards, > > Tony
Re: [PATCH] leds: leds-pca963x: workaround group blink scaling issue
On Thu, Oct 13, 2016 at 4:05 PM, Jacek Anaszewski
wrote:
> Hi Matt,
>
> On 10/13/2016 03:16 PM, Matt Ranostay wrote:
>>
>> PCA9632TK part seems to incorrectly blink at ~1.3x of the programmed
>> rate. This patchset add a nxp,period-scale devicetree property to
>> adjust for this misconfiguration.
>>
>> Cc: Tony Lindgren
>> Cc: Jacek Anaszewski
>> Signed-off-by: Matt Ranostay
>> ---
>> Documentation/devicetree/bindings/leds/pca963x.txt | 3 +++
>> drivers/leds/leds-pca963x.c| 18
>> +++---
>> 2 files changed, 18 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/leds/pca963x.txt
>> b/Documentation/devicetree/bindings/leds/pca963x.txt
>> index dafbe9931c2b..dfbdb123a9bf 100644
>> --- a/Documentation/devicetree/bindings/leds/pca963x.txt
>> +++ b/Documentation/devicetree/bindings/leds/pca963x.txt
>> @@ -7,6 +7,9 @@ Optional properties:
>> - nxp,totem-pole : use totem pole (push-pull) instead of open-drain
>> (pca9632 defaults
>>to open-drain, newer chips to totem pole)
>> - nxp,hw-blink : use hardware blinking instead of software blinking
>> +- nxp,period-scale : In some configurations, the chip blinks faster than
>> expected.
>> +This parameter provides a scaling ratio (fixed point,
>> decimal divided
>> +by 1000) to compensate, e.g. 1300=1.3x and 750=0.75x.
>
>
> Why DT property? Is it somehow dependent on the board configuration?
> How this period-scale value is calculated? Is it inferred empirically?
>
We empirically discovered and verified this with an logic analyzer on
multiple batches of this part.
Reason for the DT entry is we aren't 100% sure that it is always going
to be the same with different board revs.
Could be that parts clock acts differently with supply voltage. This
has been calculated by setting it an expected value, and measuring the
actual result with the logic analyzer.
>
>> Each led is represented as a sub-node of the nxp,pca963x device.
>>
>> diff --git a/drivers/leds/leds-pca963x.c b/drivers/leds/leds-pca963x.c
>> index 407eba11e187..b6ce1f2ec33e 100644
>> --- a/drivers/leds/leds-pca963x.c
>> +++ b/drivers/leds/leds-pca963x.c
>> @@ -59,6 +59,7 @@ struct pca963x_chipdef {
>> u8 grpfreq;
>> u8 ledout_base;
>> int n_leds;
>> + unsigned intscaling;
>> };
>>
>> static struct pca963x_chipdef pca963x_chipdefs[] = {
>> @@ -189,6 +190,14 @@ static int pca963x_led_set(struct led_classdev
>> *led_cdev,
>> return pca963x_brightness(pca963x, value);
>> }
>>
>> +static unsigned int pca963x_period_scale(struct pca963x_led *pca963x,
>> + unsigned int val)
>> +{
>> + unsigned int scaling = pca963x->chip->chipdef->scaling;
>> +
>> + return scaling ? DIV_ROUND_CLOSEST(val * scaling, 1000) : val;
>> +}
>> +
>> static int pca963x_blink_set(struct led_classdev *led_cdev,
>> unsigned long *delay_on, unsigned long *delay_off)
>> {
>> @@ -207,14 +216,14 @@ static int pca963x_blink_set(struct led_classdev
>> *led_cdev,
>> time_off = 500;
>> }
>>
>> - period = time_on + time_off;
>> + period = pca963x_period_scale(pca963x, time_on + time_off);
>>
>> /* If period not supported by hardware, default to someting sane.
>> */
>> if ((period < PCA963X_BLINK_PERIOD_MIN) ||
>> (period > PCA963X_BLINK_PERIOD_MAX)) {
>> time_on = 500;
>> time_off = 500;
>> - period = time_on + time_off;
>> + period = pca963x_period_scale(pca963x, 1000);
>> }
>>
>> /*
>> @@ -222,7 +231,7 @@ static int pca963x_blink_set(struct led_classdev
>> *led_cdev,
>> * (time_on / period) = (GDC / 256) ->
>> * GDC = ((time_on * 256) / period)
>> */
>> - gdc = (time_on * 256) / period;
>> + gdc = (pca963x_period_scale(pca963x, time_on) * 256) / period;
>>
>> /*
>> * From manual: period = ((GFRQ + 1) / 24) in seconds.
>> @@ -294,6 +303,9 @@ pca963x_dt_init(struct i2c_client *client, struct
>> pca963x_chipdef *chip)
>> else
>> pdata->blink_type = PCA963X_SW_BLINK;
>>
>> + if (of_property_read_u32(np, "nxp,period-scale", &chip->scaling))
>> + chip->scaling = 1000;
>> +
>> return pdata;
>> }
>>
>>
>
>
> --
> Best regards,
> Jacek Anaszewski
[PATCH] leds: leds-pca963x: workaround group blink scaling issue
PCA9632TK part seems to incorrectly blink at ~1.3x of the programmed
rate. This patchset add a nxp,period-scale devicetree property to
adjust for this misconfiguration.
Cc: Tony Lindgren
Cc: Jacek Anaszewski
Signed-off-by: Matt Ranostay
---
Documentation/devicetree/bindings/leds/pca963x.txt | 3 +++
drivers/leds/leds-pca963x.c| 18 +++---
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/pca963x.txt
b/Documentation/devicetree/bindings/leds/pca963x.txt
index dafbe9931c2b..dfbdb123a9bf 100644
--- a/Documentation/devicetree/bindings/leds/pca963x.txt
+++ b/Documentation/devicetree/bindings/leds/pca963x.txt
@@ -7,6 +7,9 @@ Optional properties:
- nxp,totem-pole : use totem pole (push-pull) instead of open-drain (pca9632
defaults
to open-drain, newer chips to totem pole)
- nxp,hw-blink : use hardware blinking instead of software blinking
+- nxp,period-scale : In some configurations, the chip blinks faster than
expected.
+This parameter provides a scaling ratio (fixed point,
decimal divided
+by 1000) to compensate, e.g. 1300=1.3x and 750=0.75x.
Each led is represented as a sub-node of the nxp,pca963x device.
diff --git a/drivers/leds/leds-pca963x.c b/drivers/leds/leds-pca963x.c
index 407eba11e187..b6ce1f2ec33e 100644
--- a/drivers/leds/leds-pca963x.c
+++ b/drivers/leds/leds-pca963x.c
@@ -59,6 +59,7 @@ struct pca963x_chipdef {
u8 grpfreq;
u8 ledout_base;
int n_leds;
+ unsigned intscaling;
};
static struct pca963x_chipdef pca963x_chipdefs[] = {
@@ -189,6 +190,14 @@ static int pca963x_led_set(struct led_classdev *led_cdev,
return pca963x_brightness(pca963x, value);
}
+static unsigned int pca963x_period_scale(struct pca963x_led *pca963x,
+ unsigned int val)
+{
+ unsigned int scaling = pca963x->chip->chipdef->scaling;
+
+ return scaling ? DIV_ROUND_CLOSEST(val * scaling, 1000) : val;
+}
+
static int pca963x_blink_set(struct led_classdev *led_cdev,
unsigned long *delay_on, unsigned long *delay_off)
{
@@ -207,14 +216,14 @@ static int pca963x_blink_set(struct led_classdev
*led_cdev,
time_off = 500;
}
- period = time_on + time_off;
+ period = pca963x_period_scale(pca963x, time_on + time_off);
/* If period not supported by hardware, default to someting sane. */
if ((period < PCA963X_BLINK_PERIOD_MIN) ||
(period > PCA963X_BLINK_PERIOD_MAX)) {
time_on = 500;
time_off = 500;
- period = time_on + time_off;
+ period = pca963x_period_scale(pca963x, 1000);
}
/*
@@ -222,7 +231,7 @@ static int pca963x_blink_set(struct led_classdev *led_cdev,
* (time_on / period) = (GDC / 256) ->
* GDC = ((time_on * 256) / period)
*/
- gdc = (time_on * 256) / period;
+ gdc = (pca963x_period_scale(pca963x, time_on) * 256) / period;
/*
* From manual: period = ((GFRQ + 1) / 24) in seconds.
@@ -294,6 +303,9 @@ pca963x_dt_init(struct i2c_client *client, struct
pca963x_chipdef *chip)
else
pdata->blink_type = PCA963X_SW_BLINK;
+ if (of_property_read_u32(np, "nxp,period-scale", &chip->scaling))
+ chip->scaling = 1000;
+
return pdata;
}
--
2.7.4
[PATCH] power: bq27xxx_battery: don't update poll_interval param if same
To avoid canceling the delayed workqueue needlessly, and scheduling an
immediate polling. Check if the new poll_interval value is different
than the previous setting.
Cc: Tony Lindgren
Cc: Sebastian Reichel
Signed-off-by: Matt Ranostay
---
drivers/power/supply/bq27xxx_battery.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/power/supply/bq27xxx_battery.c
b/drivers/power/supply/bq27xxx_battery.c
index d18802ca3327..e01cea9a395a 100644
--- a/drivers/power/supply/bq27xxx_battery.c
+++ b/drivers/power/supply/bq27xxx_battery.c
@@ -404,10 +404,11 @@ static LIST_HEAD(bq27xxx_battery_devices);
static int poll_interval_param_set(const char *val, const struct kernel_param
*kp)
{
struct bq27xxx_device_info *di;
+ unsigned int prev_val = *(unsigned int *) kp->arg;
int ret;
ret = param_set_uint(val, kp);
- if (ret < 0)
+ if (ret < 0 || prev_val == *(unsigned int *) kp->arg)
return ret;
mutex_lock(&bq27xxx_list_lock);
--
2.7.4
Re: [PATCH] leds: leds-pca963x: add power management support
On Fri, Sep 30, 2016 at 2:23 PM, Jacek Anaszewski
wrote:
> Hi Matt,
>
> Thanks for the patch.
>
>
> On 09/30/2016 09:27 PM, Matt Ranostay wrote:
>>
>> Turn off LEDS on suspend and put device in low power state, and restore
>> settings on resume.
>>
>> Cc: Tony Lindgren
>> Cc: Richard Purdie
>> Cc: Jacek Anaszewski
>> Signed-off-by: Matt Ranostay
>> ---
>> drivers/leds/leds-pca963x.c | 31 +++
>> 1 file changed, 31 insertions(+)
>>
>> diff --git a/drivers/leds/leds-pca963x.c b/drivers/leds/leds-pca963x.c
>> index 407eba11e187..4840bdaa1b48 100644
>> --- a/drivers/leds/leds-pca963x.c
>> +++ b/drivers/leds/leds-pca963x.c
>> @@ -382,6 +382,7 @@ static int pca963x_probe(struct i2c_client *client,
>>
>> pca963x[i].led_cdev.name = pca963x[i].name;
>> pca963x[i].led_cdev.brightness_set_blocking =
>> pca963x_led_set;
>> + pca963x[i].led_cdev.flags = LED_CORE_SUSPENDRESUME;
>>
>> if (pdata && pdata->blink_type == PCA963X_HW_BLINK)
>> pca963x[i].led_cdev.blink_set = pca963x_blink_set;
>> @@ -422,10 +423,40 @@ static int pca963x_remove(struct i2c_client *client)
>> return 0;
>> }
>>
>> +static int pca963x_set_power(struct i2c_client *client, bool state)
>> +{
>> + return i2c_smbus_write_byte_data(client, PCA963X_MODE1,
>> +state ? 0 : BIT(4));
>> +}
>> +
>> +static int pca963x_suspend(struct device *dev)
>> +{
>> + struct i2c_client *client = to_i2c_client(dev);
>> +
>> + return pca963x_set_power(client, false);
>> +}
>> +
>> +static int pca963x_resume(struct device *dev)
>> +{
>> + struct i2c_client *client = to_i2c_client(dev);
>> + int ret;
>> +
>> + ret = pca963x_set_power(client, true);
>> +
>> + /* wait for oscillator enabling */
>> + if (!ret)
>> + usleep_range(500, 1000);
>> +
>> + return ret;
>> +}
>> +
>> +static SIMPLE_DEV_PM_OPS(pca963x_pm, pca963x_suspend, pca963x_resume);
>> +
>> static struct i2c_driver pca963x_driver = {
>> .driver = {
>> .name = "leds-pca963x",
>> .of_match_table = of_match_ptr(of_pca963x_match),
>> + .pm = &pca963x_pm,
>
>
> pm ops are initialized in led-class.c. If LED_CORE_SUSPENDRESUME
> flag is set by a LED class driver, then the brightness will be
> set to 0 on suspend and brought back on resume.
Understood.
>
> LED class driver's responsibility is to enter power down mode if
> all LED class devices it exposes have their brightness set to 0.
>
> Effectively, you should avoid defining pm ops, but instead
> just track how many LEDs are on, and set the device in the power
> down mode if brightness of the last active LED is set to LED_OFF.
> Similarly the device should be powered up if any of LEDs brightness
> is set to a value greater than 0.
Ok in this case it would make sense to use runtime PM.. which
shouldn't be too hard to do. Will fix in v2
>
>> },
>> .probe = pca963x_probe,
>> .remove = pca963x_remove,
>>
>
> --
> Best regards,
> Jacek Anaszewski
[PATCH] leds: leds-pca963x: add power management support
Turn off LEDS on suspend and put device in low power state, and restore
settings on resume.
Cc: Tony Lindgren
Cc: Richard Purdie
Cc: Jacek Anaszewski
Signed-off-by: Matt Ranostay
---
drivers/leds/leds-pca963x.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/leds/leds-pca963x.c b/drivers/leds/leds-pca963x.c
index 407eba11e187..4840bdaa1b48 100644
--- a/drivers/leds/leds-pca963x.c
+++ b/drivers/leds/leds-pca963x.c
@@ -382,6 +382,7 @@ static int pca963x_probe(struct i2c_client *client,
pca963x[i].led_cdev.name = pca963x[i].name;
pca963x[i].led_cdev.brightness_set_blocking = pca963x_led_set;
+ pca963x[i].led_cdev.flags = LED_CORE_SUSPENDRESUME;
if (pdata && pdata->blink_type == PCA963X_HW_BLINK)
pca963x[i].led_cdev.blink_set = pca963x_blink_set;
@@ -422,10 +423,40 @@ static int pca963x_remove(struct i2c_client *client)
return 0;
}
+static int pca963x_set_power(struct i2c_client *client, bool state)
+{
+ return i2c_smbus_write_byte_data(client, PCA963X_MODE1,
+state ? 0 : BIT(4));
+}
+
+static int pca963x_suspend(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+
+ return pca963x_set_power(client, false);
+}
+
+static int pca963x_resume(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ int ret;
+
+ ret = pca963x_set_power(client, true);
+
+ /* wait for oscillator enabling */
+ if (!ret)
+ usleep_range(500, 1000);
+
+ return ret;
+}
+
+static SIMPLE_DEV_PM_OPS(pca963x_pm, pca963x_suspend, pca963x_resume);
+
static struct i2c_driver pca963x_driver = {
.driver = {
.name = "leds-pca963x",
.of_match_table = of_match_ptr(of_pca963x_match),
+ .pm = &pca963x_pm,
},
.probe = pca963x_probe,
.remove = pca963x_remove,
--
2.7.4
[PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query
Add POWER_SUPPLY_PROP_POLL_INTERVAL property to query and set the
polling interval of the fuel gauge.
Cc: Sebastian Reichel
Cc: Tony Lindgren
---
drivers/power/supply/bq27xxx_battery.c | 40 ++
1 file changed, 40 insertions(+)
diff --git a/drivers/power/supply/bq27xxx_battery.c
b/drivers/power/supply/bq27xxx_battery.c
index 3b0dbc689d72..d18802ca3327 100644
--- a/drivers/power/supply/bq27xxx_battery.c
+++ b/drivers/power/supply/bq27xxx_battery.c
@@ -262,6 +262,7 @@ static enum power_supply_property bq27000_battery_props[] =
{
POWER_SUPPLY_PROP_POWER_AVG,
POWER_SUPPLY_PROP_HEALTH,
POWER_SUPPLY_PROP_MANUFACTURER,
+ POWER_SUPPLY_PROP_POLL_INTERVAL,
};
static enum power_supply_property bq27010_battery_props[] = {
@@ -282,6 +283,7 @@ static enum power_supply_property bq27010_battery_props[] =
{
POWER_SUPPLY_PROP_CYCLE_COUNT,
POWER_SUPPLY_PROP_HEALTH,
POWER_SUPPLY_PROP_MANUFACTURER,
+ POWER_SUPPLY_PROP_POLL_INTERVAL,
};
static enum power_supply_property bq27500_battery_props[] = {
@@ -300,6 +302,7 @@ static enum power_supply_property bq27500_battery_props[] =
{
POWER_SUPPLY_PROP_CYCLE_COUNT,
POWER_SUPPLY_PROP_HEALTH,
POWER_SUPPLY_PROP_MANUFACTURER,
+ POWER_SUPPLY_PROP_POLL_INTERVAL,
};
static enum power_supply_property bq27530_battery_props[] = {
@@ -318,6 +321,7 @@ static enum power_supply_property bq27530_battery_props[] =
{
POWER_SUPPLY_PROP_HEALTH,
POWER_SUPPLY_PROP_CYCLE_COUNT,
POWER_SUPPLY_PROP_MANUFACTURER,
+ POWER_SUPPLY_PROP_POLL_INTERVAL,
};
static enum power_supply_property bq27541_battery_props[] = {
@@ -337,6 +341,7 @@ static enum power_supply_property bq27541_battery_props[] =
{
POWER_SUPPLY_PROP_POWER_AVG,
POWER_SUPPLY_PROP_HEALTH,
POWER_SUPPLY_PROP_MANUFACTURER,
+ POWER_SUPPLY_PROP_POLL_INTERVAL,
};
static enum power_supply_property bq27545_battery_props[] = {
@@ -355,6 +360,7 @@ static enum power_supply_property bq27545_battery_props[] =
{
POWER_SUPPLY_PROP_CYCLE_COUNT,
POWER_SUPPLY_PROP_POWER_AVG,
POWER_SUPPLY_PROP_MANUFACTURER,
+ POWER_SUPPLY_PROP_POLL_INTERVAL,
};
static enum power_supply_property bq27421_battery_props[] = {
@@ -370,6 +376,7 @@ static enum power_supply_property bq27421_battery_props[] =
{
POWER_SUPPLY_PROP_CHARGE_NOW,
POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
POWER_SUPPLY_PROP_MANUFACTURER,
+ POWER_SUPPLY_PROP_POLL_INTERVAL,
};
#define BQ27XXX_PROP(_id, _prop) \
@@ -955,6 +962,9 @@ static int bq27xxx_battery_get_property(struct power_supply
*psy,
case POWER_SUPPLY_PROP_MANUFACTURER:
val->strval = BQ27XXX_MANUFACTURER;
break;
+ case POWER_SUPPLY_PROP_POLL_INTERVAL:
+ val->intval = poll_interval;
+ break;
default:
return -EINVAL;
}
@@ -962,6 +972,34 @@ static int bq27xxx_battery_get_property(struct
power_supply *psy,
return ret;
}
+static int bq27xxx_battery_set_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ const union power_supply_propval *val)
+{
+ struct bq27xxx_device_info *di = power_supply_get_drvdata(psy);
+
+ if (psp != POWER_SUPPLY_PROP_POLL_INTERVAL)
+ return -EINVAL;
+
+ if (poll_interval == val->intval)
+ return 0;
+
+ poll_interval = val->intval;
+ cancel_delayed_work_sync(&di->work);
+ schedule_delayed_work(&di->work, 0);
+
+ return 0;
+}
+
+static int bq27xxx_property_is_writeable(struct power_supply *psy,
+enum power_supply_property psp)
+{
+ if (psp == POWER_SUPPLY_PROP_POLL_INTERVAL)
+ return 1;
+
+ return 0;
+}
+
static void bq27xxx_external_power_changed(struct power_supply *psy)
{
struct bq27xxx_device_info *di = power_supply_get_drvdata(psy);
@@ -988,6 +1026,8 @@ int bq27xxx_battery_setup(struct bq27xxx_device_info *di)
psy_desc->properties = bq27xxx_battery_props[di->chip].props;
psy_desc->num_properties = bq27xxx_battery_props[di->chip].size;
psy_desc->get_property = bq27xxx_battery_get_property;
+ psy_desc->set_property = bq27xxx_battery_set_property;
+ psy_desc->property_is_writeable = bq27xxx_property_is_writeable;
psy_desc->external_power_changed = bq27xxx_external_power_changed;
di->bat = power_supply_register_no_ws(di->dev, psy_desc, &psy_cfg);
--
2.7.4
[PATCH v2 1/2] power: power_supply: add new property POWER_SUPPLY_PROP_POLL_INTERVAL
Add new POWER_SUPPLY_PROP_POLL_INTERVAL property to display/set the
update interval in seconds of the device.
Cc: Sebastian Reichel
Cc: Tony Lindgren
---
Documentation/power/power_supply_class.txt | 1 +
drivers/power/supply/power_supply_sysfs.c | 1 +
include/linux/power_supply.h | 1 +
3 files changed, 3 insertions(+)
diff --git a/Documentation/power/power_supply_class.txt
b/Documentation/power/power_supply_class.txt
index 0c72588bd967..df9b315fe55c 100644
--- a/Documentation/power/power_supply_class.txt
+++ b/Documentation/power/power_supply_class.txt
@@ -158,6 +158,7 @@ while battery powers a load)
TIME_TO_FULL - seconds left for battery to be considered full (i.e.
while battery is charging)
+POLL_INTERVAL - seconds between queries to retrieve stats from hardware
Battery <-> external power supply interaction
~
diff --git a/drivers/power/supply/power_supply_sysfs.c
b/drivers/power/supply/power_supply_sysfs.c
index bcde8d13476a..580fd4bfe5f5 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -198,6 +198,7 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(scope),
POWER_SUPPLY_ATTR(charge_term_current),
POWER_SUPPLY_ATTR(calibrate),
+ POWER_SUPPLY_ATTR(poll_interval),
/* Properties of type `const char *' */
POWER_SUPPLY_ATTR(model_name),
POWER_SUPPLY_ATTR(manufacturer),
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 3965503315ef..8b4cfe950d3b 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -148,6 +148,7 @@ enum power_supply_property {
POWER_SUPPLY_PROP_SCOPE,
POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT,
POWER_SUPPLY_PROP_CALIBRATE,
+ POWER_SUPPLY_PROP_POLL_INTERVAL, /* in seconds! */
/* Properties of type `const char *' */
POWER_SUPPLY_PROP_MODEL_NAME,
POWER_SUPPLY_PROP_MANUFACTURER,
--
2.7.4
[PATCH v2 0/2] power_supply: add new POWER_SUPPLY_PROP_POLL_INTERVAL property
Add power supply class POWER_SUPPLY_PROP_POLL_INTERVAL to allow dynamic device statistic updating interval. Changes from v1: * Fixed milliseconds typo in commit message * Fixed file paths to drivers/power/supply * Don't update if settings are the same condition Matt Ranostay (2): power: power_supply: add new property POWER_SUPPLY_PROP_POLL_INTERVAL power: bq27xxx_battery: add poll interval property query Documentation/power/power_supply_class.txt | 1 + drivers/power/supply/bq27xxx_battery.c | 40 ++ drivers/power/supply/power_supply_sysfs.c | 1 + include/linux/power_supply.h | 1 + 4 files changed, 43 insertions(+) -- 2.7.4
Re: [RFC 1/2] power: power_supply: add new property POWER_SUPPLY_PROP_POLL_INTERVAL
On Wed, Sep 21, 2016 at 10:52 PM, Matt Ranostay wrote:
> Add new POWER_SUPPLY_PROP_POLL_INTERVAL property to display/set update
> interval in milliseconds of the device.
Should be seconds.
>
> Signed-off-by: Matt Ranostay
> ---
> Documentation/power/power_supply_class.txt | 1 +
> drivers/power/power_supply_sysfs.c | 1 +
> include/linux/power_supply.h | 1 +
> 3 files changed, 3 insertions(+)
>
> diff --git a/Documentation/power/power_supply_class.txt
> b/Documentation/power/power_supply_class.txt
> index 82dacc06e355..c2e97872374a 100644
> --- a/Documentation/power/power_supply_class.txt
> +++ b/Documentation/power/power_supply_class.txt
> @@ -158,6 +158,7 @@ while battery powers a load)
> TIME_TO_FULL - seconds left for battery to be considered full (i.e.
> while battery is charging)
>
> +POLL_INTERVAL - seconds between battery stats querying
>
> Battery <-> external power supply interaction
> ~
> diff --git a/drivers/power/power_supply_sysfs.c
> b/drivers/power/power_supply_sysfs.c
> index 80fed98832f9..df66fad322c2 100644
> --- a/drivers/power/power_supply_sysfs.c
> +++ b/drivers/power/power_supply_sysfs.c
> @@ -198,6 +198,7 @@ static struct device_attribute power_supply_attrs[] = {
> POWER_SUPPLY_ATTR(scope),
> POWER_SUPPLY_ATTR(charge_term_current),
> POWER_SUPPLY_ATTR(calibrate),
> + POWER_SUPPLY_ATTR(poll_interval),
> /* Properties of type `const char *' */
> POWER_SUPPLY_ATTR(model_name),
> POWER_SUPPLY_ATTR(manufacturer),
> diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
> index 751061790626..5d45ac511a64 100644
> --- a/include/linux/power_supply.h
> +++ b/include/linux/power_supply.h
> @@ -148,6 +148,7 @@ enum power_supply_property {
> POWER_SUPPLY_PROP_SCOPE,
> POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT,
> POWER_SUPPLY_PROP_CALIBRATE,
> + POWER_SUPPLY_PROP_POLL_INTERVAL, /* in seconds! */
> /* Properties of type `const char *' */
> POWER_SUPPLY_PROP_MODEL_NAME,
> POWER_SUPPLY_PROP_MANUFACTURER,
> --
> 2.7.4
>
Re: [PATCH] power: supply: bq24910_charger: reset first_time check
Hold off on this one. Currently reworking a patch series that won't need this change after all. On Thu, Sep 22, 2016 at 8:32 PM, Matt Ranostay wrote: > bq24190_register_reset() function needs to reset the bdi->first_time > condition every time to avoid spurious interrupts in suspend/resume. > > Signed-off-by: Matt Ranostay > --- > drivers/power/supply/bq24190_charger.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/power/supply/bq24190_charger.c > b/drivers/power/supply/bq24190_charger.c > index f5746b9f4e83..cc1dbdb1737f 100644 > --- a/drivers/power/supply/bq24190_charger.c > +++ b/drivers/power/supply/bq24190_charger.c > @@ -513,6 +513,8 @@ static int bq24190_register_reset(struct bq24190_dev_info > *bdi) > int ret, limit = 100; > u8 v; > > + bdi->first_time = true; > + > /* Reset the registers */ > ret = bq24190_write_mask(bdi, BQ24190_REG_POC, > BQ24190_REG_POC_RESET_MASK, > @@ -1375,7 +1377,6 @@ static int bq24190_probe(struct i2c_client *client, > bdi->model = id->driver_data; > strncpy(bdi->model_name, id->name, I2C_NAME_SIZE); > mutex_init(&bdi->f_reg_lock); > - bdi->first_time = true; > bdi->charger_health_valid = false; > bdi->battery_health_valid = false; > bdi->battery_status_valid = false; > -- > 2.7.4 >
[PATCH] power: supply: bq24910_charger: reset first_time check
bq24190_register_reset() function needs to reset the bdi->first_time condition every time to avoid spurious interrupts in suspend/resume. Signed-off-by: Matt Ranostay --- drivers/power/supply/bq24190_charger.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/power/supply/bq24190_charger.c b/drivers/power/supply/bq24190_charger.c index f5746b9f4e83..cc1dbdb1737f 100644 --- a/drivers/power/supply/bq24190_charger.c +++ b/drivers/power/supply/bq24190_charger.c @@ -513,6 +513,8 @@ static int bq24190_register_reset(struct bq24190_dev_info *bdi) int ret, limit = 100; u8 v; + bdi->first_time = true; + /* Reset the registers */ ret = bq24190_write_mask(bdi, BQ24190_REG_POC, BQ24190_REG_POC_RESET_MASK, @@ -1375,7 +1377,6 @@ static int bq24190_probe(struct i2c_client *client, bdi->model = id->driver_data; strncpy(bdi->model_name, id->name, I2C_NAME_SIZE); mutex_init(&bdi->f_reg_lock); - bdi->first_time = true; bdi->charger_health_valid = false; bdi->battery_health_valid = false; bdi->battery_status_valid = false; -- 2.7.4
[RFC 2/2] power: bq27xxx_battery: add poll interval property query
Add POWER_SUPPLY_PROP_POLL_INTERVAL property to query and set the
polling interval of the fuel gauge.
Signed-off-by: Matt Ranostay
---
drivers/power/bq27xxx_battery.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/drivers/power/bq27xxx_battery.c b/drivers/power/bq27xxx_battery.c
index 9cdca31ef3b2..ec6419007921 100644
--- a/drivers/power/bq27xxx_battery.c
+++ b/drivers/power/bq27xxx_battery.c
@@ -274,6 +274,7 @@ static enum power_supply_property bq27000_battery_props[] =
{
POWER_SUPPLY_PROP_POWER_AVG,
POWER_SUPPLY_PROP_HEALTH,
POWER_SUPPLY_PROP_MANUFACTURER,
+ POWER_SUPPLY_PROP_POLL_INTERVAL,
};
static enum power_supply_property bq27010_battery_props[] = {
@@ -294,6 +295,7 @@ static enum power_supply_property bq27010_battery_props[] =
{
POWER_SUPPLY_PROP_CYCLE_COUNT,
POWER_SUPPLY_PROP_HEALTH,
POWER_SUPPLY_PROP_MANUFACTURER,
+ POWER_SUPPLY_PROP_POLL_INTERVAL,
};
static enum power_supply_property bq27500_battery_props[] = {
@@ -312,6 +314,7 @@ static enum power_supply_property bq27500_battery_props[] =
{
POWER_SUPPLY_PROP_CYCLE_COUNT,
POWER_SUPPLY_PROP_HEALTH,
POWER_SUPPLY_PROP_MANUFACTURER,
+ POWER_SUPPLY_PROP_POLL_INTERVAL,
};
static enum power_supply_property bq27530_battery_props[] = {
@@ -330,6 +333,7 @@ static enum power_supply_property bq27530_battery_props[] =
{
POWER_SUPPLY_PROP_HEALTH,
POWER_SUPPLY_PROP_CYCLE_COUNT,
POWER_SUPPLY_PROP_MANUFACTURER,
+ POWER_SUPPLY_PROP_POLL_INTERVAL,
};
static enum power_supply_property bq27541_battery_props[] = {
@@ -349,6 +353,7 @@ static enum power_supply_property bq27541_battery_props[] =
{
POWER_SUPPLY_PROP_POWER_AVG,
POWER_SUPPLY_PROP_HEALTH,
POWER_SUPPLY_PROP_MANUFACTURER,
+ POWER_SUPPLY_PROP_POLL_INTERVAL,
};
static enum power_supply_property bq27545_battery_props[] = {
@@ -367,6 +372,7 @@ static enum power_supply_property bq27545_battery_props[] =
{
POWER_SUPPLY_PROP_CYCLE_COUNT,
POWER_SUPPLY_PROP_POWER_AVG,
POWER_SUPPLY_PROP_MANUFACTURER,
+ POWER_SUPPLY_PROP_POLL_INTERVAL,
};
static enum power_supply_property bq27421_battery_props[] = {
@@ -382,6 +388,7 @@ static enum power_supply_property bq27421_battery_props[] =
{
POWER_SUPPLY_PROP_CHARGE_NOW,
POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
POWER_SUPPLY_PROP_MANUFACTURER,
+ POWER_SUPPLY_PROP_POLL_INTERVAL,
};
#define BQ27XXX_PROP(_id, _prop) \
@@ -969,6 +976,9 @@ static int bq27xxx_battery_get_property(struct power_supply
*psy,
case POWER_SUPPLY_PROP_MANUFACTURER:
val->strval = BQ27XXX_MANUFACTURER;
break;
+ case POWER_SUPPLY_PROP_POLL_INTERVAL:
+ val->intval = poll_interval;
+ break;
default:
return -EINVAL;
}
@@ -976,6 +986,31 @@ static int bq27xxx_battery_get_property(struct
power_supply *psy,
return ret;
}
+static int bq27xxx_battery_set_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ const union power_supply_propval *val)
+{
+ struct bq27xxx_device_info *di = power_supply_get_drvdata(psy);
+
+ if (psp != POWER_SUPPLY_PROP_POLL_INTERVAL)
+ return -EINVAL;
+
+ poll_interval = val->intval;
+ cancel_delayed_work_sync(&di->work);
+ schedule_delayed_work(&di->work, 0);
+
+ return 0;
+}
+
+static int bq27xxx_property_is_writeable(struct power_supply *psy,
+enum power_supply_property psp)
+{
+ if (psp == POWER_SUPPLY_PROP_POLL_INTERVAL)
+ return 1;
+
+ return 0;
+}
+
static void bq27xxx_external_power_changed(struct power_supply *psy)
{
struct bq27xxx_device_info *di = power_supply_get_drvdata(psy);
@@ -1002,6 +1037,8 @@ int bq27xxx_battery_setup(struct bq27xxx_device_info *di)
psy_desc->properties = bq27xxx_battery_props[di->chip].props;
psy_desc->num_properties = bq27xxx_battery_props[di->chip].size;
psy_desc->get_property = bq27xxx_battery_get_property;
+ psy_desc->set_property = bq27xxx_battery_set_property;
+ psy_desc->property_is_writeable = bq27xxx_property_is_writeable;
psy_desc->external_power_changed = bq27xxx_external_power_changed;
di->bat = power_supply_register_no_ws(di->dev, psy_desc, &psy_cfg);
--
2.7.4
[RFC 1/2] power: power_supply: add new property POWER_SUPPLY_PROP_POLL_INTERVAL
Add new POWER_SUPPLY_PROP_POLL_INTERVAL property to display/set update
interval in milliseconds of the device.
Signed-off-by: Matt Ranostay
---
Documentation/power/power_supply_class.txt | 1 +
drivers/power/power_supply_sysfs.c | 1 +
include/linux/power_supply.h | 1 +
3 files changed, 3 insertions(+)
diff --git a/Documentation/power/power_supply_class.txt
b/Documentation/power/power_supply_class.txt
index 82dacc06e355..c2e97872374a 100644
--- a/Documentation/power/power_supply_class.txt
+++ b/Documentation/power/power_supply_class.txt
@@ -158,6 +158,7 @@ while battery powers a load)
TIME_TO_FULL - seconds left for battery to be considered full (i.e.
while battery is charging)
+POLL_INTERVAL - seconds between battery stats querying
Battery <-> external power supply interaction
~
diff --git a/drivers/power/power_supply_sysfs.c
b/drivers/power/power_supply_sysfs.c
index 80fed98832f9..df66fad322c2 100644
--- a/drivers/power/power_supply_sysfs.c
+++ b/drivers/power/power_supply_sysfs.c
@@ -198,6 +198,7 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(scope),
POWER_SUPPLY_ATTR(charge_term_current),
POWER_SUPPLY_ATTR(calibrate),
+ POWER_SUPPLY_ATTR(poll_interval),
/* Properties of type `const char *' */
POWER_SUPPLY_ATTR(model_name),
POWER_SUPPLY_ATTR(manufacturer),
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 751061790626..5d45ac511a64 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -148,6 +148,7 @@ enum power_supply_property {
POWER_SUPPLY_PROP_SCOPE,
POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT,
POWER_SUPPLY_PROP_CALIBRATE,
+ POWER_SUPPLY_PROP_POLL_INTERVAL, /* in seconds! */
/* Properties of type `const char *' */
POWER_SUPPLY_PROP_MODEL_NAME,
POWER_SUPPLY_PROP_MANUFACTURER,
--
2.7.4
[RFC 0/2] power_supply: add new POWER_SUPPLY_PROP_POLL_INTERVAL property
Some drivers should report and allow changes to the device polling interval of new stats. Matt Ranostay (2): power: power_supply: add new property POWER_SUPPLY_PROP_POLL_INTERVAL power: bq27xxx_battery: add poll interval property query Documentation/power/power_supply_class.txt | 1 + drivers/power/bq27xxx_battery.c| 37 ++ drivers/power/power_supply_sysfs.c | 1 + include/linux/power_supply.h | 1 + 4 files changed, 40 insertions(+) -- 2.7.4
[PATCH] phy: phy-twl4030-usb: emit VBUS status events to userspace
Emit KOBJ_ONLINE/KOBJ_OFFLINE action uevent on VBUS status changes. Cc: Tony Lindgren Signed-off-by: Matt Ranostay --- drivers/phy/phy-twl4030-usb.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c index d9b10a39a2cf..4830392c2fe1 100644 --- a/drivers/phy/phy-twl4030-usb.c +++ b/drivers/phy/phy-twl4030-usb.c @@ -316,6 +316,9 @@ static enum musb_vbus_id_status linkstat = MUSB_VBUS_OFF; } + kobject_uevent(&twl->dev->kobj, linkstat == MUSB_VBUS_VALID + ? KOBJ_ONLINE : KOBJ_OFFLINE); + dev_dbg(twl->dev, "HW_CONDITIONS 0x%02x/%d; link %d\n", status, status, linkstat); -- 2.7.4
[PATCH v2] power: bq27xxx_battery: allow kernel poll_interval parameter runtime update
Fix issue with poll_interval being not updated till the previous
interval expired.
Cc: Tony Lindgren
Cc: Liam Breck
Signed-off-by: Matt Ranostay
---
Changes from v1:
* Change param_get_ushort to param_get_uint
* Changed param_lock naming to more precise bq27xxx_list_lock
drivers/power/supply/bq27xxx_battery.c | 38 +-
include/linux/power/bq27xxx_battery.h | 1 +
2 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/power/supply/bq27xxx_battery.c
b/drivers/power/supply/bq27xxx_battery.c
index 3f57dd54803a..3b0dbc689d72 100644
--- a/drivers/power/supply/bq27xxx_battery.c
+++ b/drivers/power/supply/bq27xxx_battery.c
@@ -39,6 +39,7 @@
#include
#include
+#include
#include
#include
#include
@@ -390,8 +391,35 @@ static struct {
BQ27XXX_PROP(BQ27421, bq27421_battery_props),
};
+static DEFINE_MUTEX(bq27xxx_list_lock);
+static LIST_HEAD(bq27xxx_battery_devices);
+
+static int poll_interval_param_set(const char *val, const struct kernel_param
*kp)
+{
+ struct bq27xxx_device_info *di;
+ int ret;
+
+ ret = param_set_uint(val, kp);
+ if (ret < 0)
+ return ret;
+
+ mutex_lock(&bq27xxx_list_lock);
+ list_for_each_entry(di, &bq27xxx_battery_devices, list) {
+ cancel_delayed_work_sync(&di->work);
+ schedule_delayed_work(&di->work, 0);
+ }
+ mutex_unlock(&bq27xxx_list_lock);
+
+ return ret;
+}
+
+static const struct kernel_param_ops param_ops_poll_interval = {
+ .get = param_get_uint,
+ .set = poll_interval_param_set,
+};
+
static unsigned int poll_interval = 360;
-module_param(poll_interval, uint, 0644);
+module_param_cb(poll_interval, ¶m_ops_poll_interval, &poll_interval, 0644);
MODULE_PARM_DESC(poll_interval,
"battery poll interval in seconds - 0 disables polling");
@@ -972,6 +1000,10 @@ int bq27xxx_battery_setup(struct bq27xxx_device_info *di)
bq27xxx_battery_update(di);
+ mutex_lock(&bq27xxx_list_lock);
+ list_add(&di->list, &bq27xxx_battery_devices);
+ mutex_unlock(&bq27xxx_list_lock);
+
return 0;
}
EXPORT_SYMBOL_GPL(bq27xxx_battery_setup);
@@ -990,6 +1022,10 @@ void bq27xxx_battery_teardown(struct bq27xxx_device_info
*di)
power_supply_unregister(di->bat);
+ mutex_lock(&bq27xxx_list_lock);
+ list_del(&di->list);
+ mutex_unlock(&bq27xxx_list_lock);
+
mutex_destroy(&di->lock);
}
EXPORT_SYMBOL_GPL(bq27xxx_battery_teardown);
diff --git a/include/linux/power/bq27xxx_battery.h
b/include/linux/power/bq27xxx_battery.h
index b50c0492629d..e30deb046156 100644
--- a/include/linux/power/bq27xxx_battery.h
+++ b/include/linux/power/bq27xxx_battery.h
@@ -58,6 +58,7 @@ struct bq27xxx_device_info {
unsigned long last_update;
struct delayed_work work;
struct power_supply *bat;
+ struct list_head list;
struct mutex lock;
u8 *regs;
};
--
2.7.4
Re: [PATCH 1/2] power: bq27xxx_battery: add configurable poll_interval by sysfs
On Mon, Sep 19, 2016 at 12:46 PM, Sebastian Reichel wrote: > Hi, > > On Fri, Sep 16, 2016 at 08:42:54PM -0700, Matt Ranostay wrote: >> Allow the poll_interval to be runtime configurable via an sysfs >> entry. This is needed for udev control of the poll interval. >> >> Signed-off-by: Matt Ranostay >> --- >> drivers/power/supply/bq27xxx_battery.c | 48 >> +- >> 1 file changed, 47 insertions(+), 1 deletion(-) > > New sysfs attributes should be documented in Documentation/ABI. Yeah I should know better :) > > Also I'm not too keen to add this, as there is already the sysfs > entry for the module parameter. I don't see any reason why udev > should not be able to change that value, so fix udev instead of > duplicating functionality in the kernel. Yeah duplication is bad. We are wondering if having a POWER_SUPPLY_PROP_UPDATE_INTERVAL would be an more acceptable solution. Of course this would need to be made generic and not a per driver solution as it is now. Thanks, Matt > > -- Sebastian
