* Re: [PATCH v2 1/6] iio: bmi160: Add of device table for i2c
From: Jonathan Cameron @ 2016-12-30 10:47 UTC (permalink / raw)
To: Marcin Niestroj
Cc: Peter Meerwald-Stadler, Hartmut Knaack, Lars-Peter Clausen,
Daniel Baluta, Gregor Boirie, Sanchayan Maity, Rob Herring,
Mark Rutland, linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161208142259.26230-2-m.niestroj-z3quKL4iOrmQ6ZAhV5LmOA@public.gmane.org>
On 08/12/16 14:22, Marcin Niestroj wrote:
> From now on we can add bmi160 device to device-tree by specifying
> compatible string.
>
> Signed-off-by: Marcin Niestroj <m.niestroj-z3quKL4iOrmQ6ZAhV5LmOA@public.gmane.org>
Other than the fact this should really have been two patches, this looks good.
Applied to the togreg branch of iio.git and pushed out as testing for the autobuilders
to play with it.
Thanks,
Jonathan
> ---
> Patch introduced in v2
>
> drivers/iio/imu/bmi160/bmi160_i2c.c | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/imu/bmi160/bmi160_i2c.c b/drivers/iio/imu/bmi160/bmi160_i2c.c
> index 07a179d..155a31f 100644
> --- a/drivers/iio/imu/bmi160/bmi160_i2c.c
> +++ b/drivers/iio/imu/bmi160/bmi160_i2c.c
> @@ -11,10 +11,11 @@
> * - 0x68 if SDO is pulled to GND
> * - 0x69 if SDO is pulled to VDDIO
> */
> -#include <linux/module.h>
> +#include <linux/acpi.h>
> #include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> #include <linux/regmap.h>
> -#include <linux/acpi.h>
Whilst I have no objection to reordering headers so they are alphabetical
(as long as not clarity is lost) it should really be in it's own patch...
>
> #include "bmi160.h"
>
> @@ -56,10 +57,19 @@ static const struct acpi_device_id bmi160_acpi_match[] = {
> };
> MODULE_DEVICE_TABLE(acpi, bmi160_acpi_match);
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id bmi160_of_match[] = {
> + { .compatible = "bosch,bmi160" },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, bmi160_of_match);
> +#endif
> +
> static struct i2c_driver bmi160_i2c_driver = {
> .driver = {
> .name = "bmi160_i2c",
> .acpi_match_table = ACPI_PTR(bmi160_acpi_match),
> + .of_match_table = of_match_ptr(bmi160_of_match),
> },
> .probe = bmi160_i2c_probe,
> .remove = bmi160_i2c_remove,
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 5/6] iio: bmi160: Fix time needed to sleep after command execution
From: Jonathan Cameron @ 2016-12-30 10:49 UTC (permalink / raw)
To: Marcin Niestroj
Cc: Peter Meerwald-Stadler, Hartmut Knaack, Lars-Peter Clausen,
Daniel Baluta, Gregor Boirie, Sanchayan Maity, Rob Herring,
Mark Rutland, linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161208142259.26230-6-m.niestroj-z3quKL4iOrmQ6ZAhV5LmOA@public.gmane.org>
On 08/12/16 14:22, Marcin Niestroj wrote:
> Datasheet specifies typical and maximum execution times for which CMD
> register is occupied after previous command execution. We took these
> values as minimum and maximum time for usleep_range() call before making
> a new command execution.
>
> To be sure, that the CMD register is no longer occupied we need to wait
> *at least* the maximum time specified by datasheet.
>
> Signed-off-by: Marcin Niestroj <m.niestroj-z3quKL4iOrmQ6ZAhV5LmOA@public.gmane.org>
This looks like a definite bug that we would want to fix in stable as well.
If possible, could you ensure this is the first patch in the updated series?
Thanks,
Jonathan
> ---
> Patch introduced in v2
>
> drivers/iio/imu/bmi160/bmi160_core.c | 25 ++++++-------------------
> 1 file changed, 6 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/iio/imu/bmi160/bmi160_core.c b/drivers/iio/imu/bmi160/bmi160_core.c
> index 095533c..88bcf3f 100644
> --- a/drivers/iio/imu/bmi160/bmi160_core.c
> +++ b/drivers/iio/imu/bmi160/bmi160_core.c
> @@ -67,10 +67,8 @@
>
> #define BMI160_REG_DUMMY 0x7F
>
> -#define BMI160_ACCEL_PMU_MIN_USLEEP 3200
> -#define BMI160_ACCEL_PMU_MAX_USLEEP 3800
> -#define BMI160_GYRO_PMU_MIN_USLEEP 55000
> -#define BMI160_GYRO_PMU_MAX_USLEEP 80000
> +#define BMI160_ACCEL_PMU_MIN_USLEEP 3800
> +#define BMI160_GYRO_PMU_MIN_USLEEP 80000
> #define BMI160_SOFTRESET_USLEEP 1000
>
> #define BMI160_CHANNEL(_type, _axis, _index) { \
> @@ -153,20 +151,9 @@ static struct bmi160_regs bmi160_regs[] = {
> },
> };
>
> -struct bmi160_pmu_time {
> - unsigned long min;
> - unsigned long max;
> -};
> -
> -static struct bmi160_pmu_time bmi160_pmu_time[] = {
> - [BMI160_ACCEL] = {
> - .min = BMI160_ACCEL_PMU_MIN_USLEEP,
> - .max = BMI160_ACCEL_PMU_MAX_USLEEP
> - },
> - [BMI160_GYRO] = {
> - .min = BMI160_GYRO_PMU_MIN_USLEEP,
> - .max = BMI160_GYRO_PMU_MIN_USLEEP,
> - },
> +static unsigned long bmi160_pmu_time[] = {
> + [BMI160_ACCEL] = BMI160_ACCEL_PMU_MIN_USLEEP,
> + [BMI160_GYRO] = BMI160_GYRO_PMU_MIN_USLEEP,
> };
>
> struct bmi160_scale {
> @@ -293,7 +280,7 @@ int bmi160_set_mode(struct bmi160_data *data, enum bmi160_sensor_type t,
> if (ret < 0)
> return ret;
>
> - usleep_range(bmi160_pmu_time[t].min, bmi160_pmu_time[t].max);
> + usleep_range(bmi160_pmu_time[t], bmi160_pmu_time[t] + 1000);
>
> return 0;
> }
>
^ permalink raw reply
* Re: [PATCH v2 5/6] iio: bmi160: Fix time needed to sleep after command execution
From: Jonathan Cameron @ 2016-12-30 10:51 UTC (permalink / raw)
To: Marcin Niestroj
Cc: Peter Meerwald-Stadler, Hartmut Knaack, Lars-Peter Clausen,
Daniel Baluta, Gregor Boirie, Sanchayan Maity, Rob Herring,
Mark Rutland, linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <7668f191-dafd-e616-171a-cafc52791292-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On 30/12/16 10:49, Jonathan Cameron wrote:
> On 08/12/16 14:22, Marcin Niestroj wrote:
>> Datasheet specifies typical and maximum execution times for which CMD
>> register is occupied after previous command execution. We took these
>> values as minimum and maximum time for usleep_range() call before making
>> a new command execution.
>>
>> To be sure, that the CMD register is no longer occupied we need to wait
>> *at least* the maximum time specified by datasheet.
>>
>> Signed-off-by: Marcin Niestroj <m.niestroj-z3quKL4iOrmQ6ZAhV5LmOA@public.gmane.org>
> This looks like a definite bug that we would want to fix in stable as well.
> If possible, could you ensure this is the first patch in the updated series?
Actually don't worry. It applies cleanly to my fixes-togreg-post-rc1 branch anyway
so I'll take it that way and send upstream asap.
Applied to the fixes-togreg-post-rc1 branch and marked for stable.
Thanks,
Jonathan
>
> Thanks,
>
> Jonathan
>> ---
>> Patch introduced in v2
>>
>> drivers/iio/imu/bmi160/bmi160_core.c | 25 ++++++-------------------
>> 1 file changed, 6 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/iio/imu/bmi160/bmi160_core.c b/drivers/iio/imu/bmi160/bmi160_core.c
>> index 095533c..88bcf3f 100644
>> --- a/drivers/iio/imu/bmi160/bmi160_core.c
>> +++ b/drivers/iio/imu/bmi160/bmi160_core.c
>> @@ -67,10 +67,8 @@
>>
>> #define BMI160_REG_DUMMY 0x7F
>>
>> -#define BMI160_ACCEL_PMU_MIN_USLEEP 3200
>> -#define BMI160_ACCEL_PMU_MAX_USLEEP 3800
>> -#define BMI160_GYRO_PMU_MIN_USLEEP 55000
>> -#define BMI160_GYRO_PMU_MAX_USLEEP 80000
>> +#define BMI160_ACCEL_PMU_MIN_USLEEP 3800
>> +#define BMI160_GYRO_PMU_MIN_USLEEP 80000
>> #define BMI160_SOFTRESET_USLEEP 1000
>>
>> #define BMI160_CHANNEL(_type, _axis, _index) { \
>> @@ -153,20 +151,9 @@ static struct bmi160_regs bmi160_regs[] = {
>> },
>> };
>>
>> -struct bmi160_pmu_time {
>> - unsigned long min;
>> - unsigned long max;
>> -};
>> -
>> -static struct bmi160_pmu_time bmi160_pmu_time[] = {
>> - [BMI160_ACCEL] = {
>> - .min = BMI160_ACCEL_PMU_MIN_USLEEP,
>> - .max = BMI160_ACCEL_PMU_MAX_USLEEP
>> - },
>> - [BMI160_GYRO] = {
>> - .min = BMI160_GYRO_PMU_MIN_USLEEP,
>> - .max = BMI160_GYRO_PMU_MIN_USLEEP,
>> - },
>> +static unsigned long bmi160_pmu_time[] = {
>> + [BMI160_ACCEL] = BMI160_ACCEL_PMU_MIN_USLEEP,
>> + [BMI160_GYRO] = BMI160_GYRO_PMU_MIN_USLEEP,
>> };
>>
>> struct bmi160_scale {
>> @@ -293,7 +280,7 @@ int bmi160_set_mode(struct bmi160_data *data, enum bmi160_sensor_type t,
>> if (ret < 0)
>> return ret;
>>
>> - usleep_range(bmi160_pmu_time[t].min, bmi160_pmu_time[t].max);
>> + usleep_range(bmi160_pmu_time[t], bmi160_pmu_time[t] + 1000);
>>
>> return 0;
>> }
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 2/3][v2] arm64: freescale: ls2080a: Split devicetree for code resuability
From: Shawn Guo @ 2016-12-30 11:26 UTC (permalink / raw)
To: Abhimanyu Saini
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, scott.wood-3arQi8VN3Tc,
stuart.yoder-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Priyanka Jain,
Ashish Kumar
In-Reply-To: <1480325824-14649-3-git-send-email-abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
On Mon, Nov 28, 2016 at 03:07:03PM +0530, Abhimanyu Saini wrote:
> LS2088A and LS2080A are similar SoCs with a few differences like
> ARM cores etc.
>
> Reorganize the LS2080A device tree to move the common nodes to:
> - fsl-ls2080a-ls2088a.dtsi
> - fsl-ls2080a-ls2088a-rdb.dts
> - fsl-ls2080a-ls2088a-qds.dts
I do not quite like the naming of these files. Will the following one
be better?
- fsl-ls208xa.dtsi
- fsl-ls208xa-rdb.dtsi
- fsl-ls208xa-qds.dtsi
Also if a DTS file is only to be included by another one, not to
generate a DTB, we name it .dtsi rather than .dts.
Shawn
>
> Signed-off-by: Abhimanyu Saini <abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Priyanka Jain <priyanka.jain-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Ashish Kumar <ashish.kumar-3arQi8VN3Tc@public.gmane.org>
> ---
> .../boot/dts/freescale/fsl-ls2080a-ls2088a-qds.dts | 196 ++++++
> .../boot/dts/freescale/fsl-ls2080a-ls2088a-rdb.dts | 152 +++++
> .../boot/dts/freescale/fsl-ls2080a-ls2088a.dtsi | 727 +++++++++++++++++++++
> arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts | 154 +----
> arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts | 110 +---
> arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 706 +-------------------
> 6 files changed, 1100 insertions(+), 945 deletions(-)
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2080a-ls2088a-qds.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2080a-ls2088a-rdb.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2080a-ls2088a.dtsi
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 6/6] iio: bmi160: Support hardware fifo
From: Jonathan Cameron @ 2016-12-30 11:29 UTC (permalink / raw)
To: Marcin Niestroj
Cc: Peter Meerwald-Stadler, Hartmut Knaack, Lars-Peter Clausen,
Daniel Baluta, Gregor Boirie, Sanchayan Maity, Rob Herring,
Mark Rutland, linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161208142259.26230-7-m.niestroj-z3quKL4iOrmQ6ZAhV5LmOA@public.gmane.org>
On 08/12/16 14:22, Marcin Niestroj wrote:
> This patch was developed primarily based on bmc150_accel hardware fifo
> implementation.
>
> IRQ handler was added, which for now is responsible only for handling
> watermark interrupts. The BMI160 chip has two interrupt outputs. By
> default INT is considered to be connected. If INT2 is used instead, the
> interrupt-names device-tree property can be used to specify that.
>
> Signed-off-by: Marcin Niestroj <m.niestroj-z3quKL4iOrmQ6ZAhV5LmOA@public.gmane.org>
A few bits and bobs inline but basically looking good to me.
Sorry for the delay in getting around to review this! I'd like some input
from Daniel ideally as well, but he is rather busy at the moment so I may
take the final version of this without hearing from him.
thanks,
Jonathan
> ---
> Depends on patch 4 in series
>
> Changes v1 -> v2:
> * add __ prefix to all functions that should be called with mutex held
> (suggested by Peter)
> * get rid of non-constant array size (suggested by Peter)
> * disable irq on init failure and module removal (suggested by Peter)
> * make bmi160_buffer_predisable() the reverse order of the
> bmi160_buffer_postenable() (suggested by Jonathan)
> * remove realignment for iio_info structs (suggested by Jonathan)
>
> drivers/iio/imu/bmi160/bmi160.h | 3 +-
> drivers/iio/imu/bmi160/bmi160_core.c | 618 ++++++++++++++++++++++++++++++++++-
> drivers/iio/imu/bmi160/bmi160_i2c.c | 7 +-
> drivers/iio/imu/bmi160/bmi160_spi.c | 3 +-
> 4 files changed, 613 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/iio/imu/bmi160/bmi160.h b/drivers/iio/imu/bmi160/bmi160.h
> index d2ae6ed..4a7c10e 100644
> --- a/drivers/iio/imu/bmi160/bmi160.h
> +++ b/drivers/iio/imu/bmi160/bmi160.h
> @@ -4,7 +4,8 @@
> extern const struct regmap_config bmi160_regmap_config;
>
> int bmi160_core_probe(struct device *dev, struct regmap *regmap,
> - const char *name, bool use_spi);
> + const char *name, int irq,
> + bool use_spi, bool block_supported);
> void bmi160_core_remove(struct device *dev);
>
> #endif /* BMI160_H_ */
> diff --git a/drivers/iio/imu/bmi160/bmi160_core.c b/drivers/iio/imu/bmi160/bmi160_core.c
> index 88bcf3f..26404b4 100644
> --- a/drivers/iio/imu/bmi160/bmi160_core.c
> +++ b/drivers/iio/imu/bmi160/bmi160_core.c
> @@ -10,7 +10,7 @@
> *
> * IIO core driver for BMI160, with support for I2C/SPI busses
> *
> - * TODO: magnetometer, interrupts, hardware FIFO
> + * TODO: magnetometer, interrupts
> */
> #include <linux/module.h>
> #include <linux/regmap.h>
> @@ -23,8 +23,12 @@
> #include <linux/iio/buffer.h>
> #include <linux/iio/sysfs.h>
>
> +#include <linux/of_irq.h>
> +
> #include "bmi160.h"
>
> +#define BMI160_IRQ_NAME "bmi160_event"
Does the device actually support different uses for the two irqs at the
same time? If not I'd be tempted ot just call this bmi160
> +
> #define BMI160_REG_CHIP_ID 0x00
> #define BMI160_CHIP_ID_VAL 0xD1
>
> @@ -35,6 +39,21 @@
> #define BMI160_REG_DATA_GYRO_XOUT_L 0x0C
> #define BMI160_REG_DATA_ACCEL_XOUT_L 0x12
>
> +#define BMI160_REG_STATUS 0x1B
> +#define BMI160_STATUS_MAG_MAN_OP BIT(2)
> +
> +#define BMI160_REG_INT_STATUS0 0x1C
> +
> +#define BMI160_REG_INT_STATUS1 0x1D
> +#define BMI160_INT_STATUS_FWM BIT(6)
> +
> +#define BMI160_REG_INT_STATUS2 0x1E
> +
> +#define BMI160_REG_INT_STATUS3 0x1F
> +
> +#define BMI160_REG_FIFO_LENGTH 0x22
> +#define BMI160_REG_FIFO_DATA 0x24
> +
> #define BMI160_REG_ACCEL_CONFIG 0x40
> #define BMI160_ACCEL_CONFIG_ODR_MASK GENMASK(3, 0)
> #define BMI160_ACCEL_CONFIG_BWP_MASK GENMASK(6, 4)
> @@ -56,6 +75,36 @@
> #define BMI160_GYRO_RANGE_250DPS 0x03
> #define BMI160_GYRO_RANGE_125DPS 0x04
>
> +#define BMI160_REG_FIFO_CONFIG_0 0x46
> +
> +#define BMI160_REG_FIFO_CONFIG_1 0x47
> +#define BMI160_FIFO_GYRO_EN BIT(7)
> +#define BMI160_FIFO_ACCEL_EN BIT(6)
> +#define BMI160_FIFO_MAGN_EN BIT(5)
> +#define BMI160_FIFO_HEADER_EN BIT(4)
> +#define BMI160_FIFO_TAG_INT1_EN BIT(3)
> +#define BMI160_FIFO_TAG_INT2_EN BIT(2)
> +#define BMI160_FIFO_TIME_EN BIT(1)
> +
> +#define BMI160_REG_INT_EN_1 0x51
> +#define BMI160_INT_FWM_EN BIT(6)
> +#define BMI160_INT_FFULL_EN BIT(5)
> +#define BMI160_INT_DRDY_EN BIT(4)
> +
> +#define BMI160_REG_INT_OUT_CTRL 0x53
> +#define BMI160_INT2_OUTPUT_EN BIT(7)
> +#define BMI160_INT1_OUTPUT_EN BIT(3)
> +
> +#define BMI160_REG_INT_LATCH 0x54
> +
> +#define BMI160_REG_INT_MAP_1 0x56
> +#define BMI160_INT1_MAP_DRDY BIT(7)
> +#define BMI160_INT1_MAP_FWM BIT(6)
> +#define BMI160_INT1_MAP_FFULL BIT(5)
> +#define BMI160_INT2_MAP_DRDY BIT(3)
> +#define BMI160_INT2_MAP_FWM BIT(2)
> +#define BMI160_INT2_MAP_FFULL BIT(1)
> +
> #define BMI160_REG_CMD 0x7E
> #define BMI160_CMD_ACCEL_PM_SUSPEND 0x10
> #define BMI160_CMD_ACCEL_PM_NORMAL 0x11
> @@ -67,6 +116,8 @@
>
> #define BMI160_REG_DUMMY 0x7F
>
> +#define BMI160_FIFO_LENGTH 1024
> +
> #define BMI160_ACCEL_PMU_MIN_USLEEP 3800
> #define BMI160_GYRO_PMU_MIN_USLEEP 80000
> #define BMI160_SOFTRESET_USLEEP 1000
> @@ -109,9 +160,34 @@ enum bmi160_sensor_type {
> BMI160_NUM_SENSORS /* must be last */
> };
>
> +struct bmi160_irq_data {
> + unsigned int map_fwm;
> + unsigned int output_en;
> +};
> +
> +static const struct bmi160_irq_data bmi160_irq1_data = {
> + .map_fwm = BMI160_INT1_MAP_FWM,
> + .output_en = BMI160_INT1_OUTPUT_EN,
> +};
> +
> +static const struct bmi160_irq_data bmi160_irq2_data = {
> + .map_fwm = BMI160_INT2_MAP_FWM,
> + .output_en = BMI160_INT2_OUTPUT_EN,
> +};
> +
> struct bmi160_data {
> struct regmap *regmap;
> struct mutex mutex;
> + const struct bmi160_irq_data *irq_data;
> + int irq;
> + bool irq_enabled;
> + int64_t timestamp;
> + int64_t fifo_sample_period;
> + bool fifo_enabled;
> + unsigned int fifo_config;
> + unsigned int fifo_sample_size;
> + u8 *fifo_buffer;
> + unsigned int watermark;
> };
>
> const struct regmap_config bmi160_regmap_config = {
> @@ -374,16 +450,20 @@ int bmi160_set_odr(struct bmi160_data *data, enum bmi160_sensor_type t,
> return ret;
> }
>
> -static int bmi160_get_odr(struct bmi160_data *data, enum bmi160_sensor_type t,
> - int *odr, int *uodr)
> +static int64_t bmi160_frequency_to_period(int odr, int uodr)
> {
> - int i, val, ret;
> + uint64_t period = 1000000000000000;
> + int64_t frequency = (int64_t) odr * 1000000 + uodr;
>
> - mutex_lock(&data->mutex);
> - ret = regmap_read(data->regmap, bmi160_regs[t].config, &val);
> - mutex_unlock(&data->mutex);
> - if (ret < 0)
> - return ret;
> + do_div(period, frequency);
> +
> + return period;
> +}
> +
> +static const struct bmi160_odr *bmi160_reg_to_odr(enum bmi160_sensor_type t,
> + unsigned int val)
> +{
> + int i;
>
> val &= bmi160_regs[t].config_odr_mask;
>
> @@ -392,10 +472,52 @@ static int bmi160_get_odr(struct bmi160_data *data, enum bmi160_sensor_type t,
> break;
>
> if (i >= bmi160_odr_table[t].num)
> - return -EINVAL;
> + return ERR_PTR(-EINVAL);
>
> - *odr = bmi160_odr_table[t].tbl[i].odr;
> - *uodr = bmi160_odr_table[t].tbl[i].uodr;
> + return &bmi160_odr_table[t].tbl[i];
> +}
> +
> +static int __bmi160_get_sample_period(struct bmi160_data *data,
> + enum bmi160_sensor_type t,
> + int64_t *sample_period)
> +{
> + const struct bmi160_odr *odr_entry;
> + int ret;
> + unsigned int val;
> +
> + ret = regmap_read(data->regmap, bmi160_regs[t].config, &val);
> + if (ret < 0)
> + return ret;
> +
> + odr_entry = bmi160_reg_to_odr(t, val);
> + if (IS_ERR(odr_entry))
> + return PTR_ERR(odr_entry);
> +
> + *sample_period = bmi160_frequency_to_period(odr_entry->odr,
> + odr_entry->uodr);
> +
> + return 0;
> +}
> +
> +static int bmi160_get_odr(struct bmi160_data *data, enum bmi160_sensor_type t,
> + int *odr, int *uodr)
> +{
> + const struct bmi160_odr *odr_entry;
> + int ret;
> + unsigned int val;
> +
> + mutex_lock(&data->mutex);
> + ret = regmap_read(data->regmap, bmi160_regs[t].config, &val);
> + mutex_unlock(&data->mutex);
> + if (ret < 0)
> + return ret;
> +
> + odr_entry = bmi160_reg_to_odr(t, val);
> + if (IS_ERR(odr_entry))
> + return PTR_ERR(odr_entry);
> +
> + *odr = odr_entry->odr;
> + *uodr = odr_entry->uodr;
>
> return 0;
> }
> @@ -504,6 +626,356 @@ static const struct attribute_group bmi160_attrs_group = {
> .attrs = bmi160_attrs,
> };
>
> +static int __bmi160_read_sample_period(struct bmi160_data *data,
> + enum bmi160_sensor_type sensor_type)
> +{
> + struct device *dev = regmap_get_device(data->regmap);
> + int64_t uninitialized_var(sample_period);
> + int ret;
> +
> + ret = __bmi160_get_sample_period(data, sensor_type, &sample_period);
> + if (ret < 0)
> + return ret;
> +
> + if (data->fifo_sample_period) {
> + if (data->fifo_sample_period != sample_period) {
Ah, I was wondering how you got around this restriction. A bit more limiting
than having two separate buffers would have been, but easier to handle and
I do wonder how often people actually run these devices with different
sampling frequencies...
> + dev_warn(dev, "Enabled sensors have unequal ODR values\n");
> + return -EINVAL;
> + }
> + } else {
> + data->fifo_sample_period = sample_period;
> + }
> +
> + return 0;
> +}
> +
> +static int __bmi160_fifo_enable(struct iio_dev *indio_dev,
> + struct bmi160_data *data)
> +{
> + struct regmap *regmap = data->regmap;
> + struct device *dev = regmap_get_device(regmap);
> + int ret;
> + int i;
> + unsigned int val;
> + unsigned int fifo_config = 0;
> +
> + /* Set fifo sample size and period */
> + for_each_set_bit(i, indio_dev->active_scan_mask,
> + indio_dev->masklength) {
> + if (i <= BMI160_SCAN_GYRO_Z)
> + fifo_config |= BMI160_FIFO_GYRO_EN;
> + else if (i <= BMI160_SCAN_ACCEL_Z)
> + fifo_config |= BMI160_FIFO_ACCEL_EN;
> + }
> +
> + data->fifo_sample_period = 0;
> + data->fifo_sample_size = 0;
> + if (fifo_config & BMI160_FIFO_GYRO_EN) {
> + data->fifo_sample_size += 6;
> + ret = __bmi160_read_sample_period(data, BMI160_GYRO);
> + if (ret < 0)
> + return ret;
> + }
> + if (fifo_config & BMI160_FIFO_ACCEL_EN) {
> + data->fifo_sample_size += 6;
> + ret = __bmi160_read_sample_period(data, BMI160_ACCEL);
> + if (ret < 0)
> + return ret;
> + }
> +
> + /*
> + * Set watermark level and write real value back, as it will be used
> + * in timestamp calculation.
> + */
> + val = data->watermark * data->fifo_sample_size;
> + if (val > BMI160_FIFO_LENGTH - 1) {
> + val = BMI160_FIFO_LENGTH - 1;
> + data->watermark = val / data->fifo_sample_size;
> + }
> + val = data->watermark * data->fifo_sample_size / 4;
> +
> + ret = regmap_write(regmap, BMI160_REG_FIFO_CONFIG_0, val);
> + if (ret < 0) {
> + dev_err(dev, "Failed to set watermark\n");
> + return ret;
> + }
> +
> + /* Enable FIFO channels */
> + ret = regmap_write(regmap, BMI160_REG_FIFO_CONFIG_1,
> + fifo_config);
> + if (ret < 0) {
> + dev_err(dev, "Failed to write FIFO_CONFIG_1\n");
> + return ret;
> + }
> +
> + data->fifo_config = fifo_config;
> + data->fifo_enabled = true;
> +
> + return 0;
> +}
> +
> +static int __bmi160_fifo_disable(struct bmi160_data *data)
> +{
> + struct regmap *regmap = data->regmap;
> + struct device *dev = regmap_get_device(regmap);
> + int ret;
> +
> + /* Disable all FIFO channels */
> + ret = regmap_write(regmap, BMI160_REG_FIFO_CONFIG_1, 0);
> + if (ret < 0) {
> + dev_err(dev, "Failed to write FIFO_CONFIG_1\n");
> + return ret;
> + }
> +
> + data->fifo_enabled = false;
> +
> + return 0;
> +}
> +
> +static int bmi160_buffer_postenable(struct iio_dev *indio_dev)
> +{
> + struct bmi160_data *data = iio_priv(indio_dev);
> + int ret;
> +
> + if (indio_dev->currentmode == INDIO_BUFFER_TRIGGERED)
> + return iio_triggered_buffer_postenable(indio_dev);
> +
> + mutex_lock(&data->mutex);
> + ret = __bmi160_fifo_enable(indio_dev, data);
> + if (ret < 0)
> + goto unlock;
> +
> + ret = regmap_update_bits(data->regmap, BMI160_REG_INT_MAP_1,
> + data->irq_data->map_fwm, data->irq_data->map_fwm);
> + if (ret < 0)
> + goto unlock;
> +
> + ret = regmap_update_bits(data->regmap, BMI160_REG_INT_EN_1,
> + BMI160_INT_FWM_EN, BMI160_INT_FWM_EN);
> +
> +unlock:
> + mutex_unlock(&data->mutex);
> +
> + return ret;
> +}
> +
> +static int bmi160_buffer_predisable(struct iio_dev *indio_dev)
> +{
> + struct bmi160_data *data = iio_priv(indio_dev);
> + struct regmap *regmap = data->regmap;
> + int ret = 0;
> +
> + if (indio_dev->currentmode == INDIO_BUFFER_TRIGGERED)
> + return iio_triggered_buffer_predisable(indio_dev);
> +
> + mutex_lock(&data->mutex);
> + ret = regmap_update_bits(regmap, BMI160_REG_INT_EN_1,
> + BMI160_INT_FWM_EN, 0);
> + if (ret < 0)
> + goto unlock;
> +
> + ret = regmap_update_bits(data->regmap, BMI160_REG_INT_MAP_1,
> + data->irq_data->map_fwm, 0);
> + if (ret < 0)
> + goto unlock;
> +
> + ret = __bmi160_fifo_disable(data);
> +
> +unlock:
> + mutex_unlock(&data->mutex);
> +
> + return ret;
> +}
> +
> +static const struct iio_buffer_setup_ops bmi160_buffer_ops = {
> + .postenable = bmi160_buffer_postenable,
> + .predisable = bmi160_buffer_predisable,
> +};
> +
> +static ssize_t bmi160_get_fifo_state(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> + struct bmi160_data *data = iio_priv(indio_dev);
> + bool state;
> +
> + mutex_lock(&data->mutex);
> + state = data->fifo_enabled;
> + mutex_unlock(&data->mutex);
> +
> + return sprintf(buf, "%d\n", (int) state);
> +}
> +
> +static ssize_t bmi160_get_fifo_watermark(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> + struct bmi160_data *data = iio_priv(indio_dev);
> + int wm;
> +
> + mutex_lock(&data->mutex);
> + wm = data->watermark;
> + mutex_unlock(&data->mutex);
> +
> + return sprintf(buf, "%d\n", wm);
> +}
> +
> +static IIO_CONST_ATTR(hwfifo_watermark_min, "1");
> +static IIO_CONST_ATTR(hwfifo_watermark_max,
> + __stringify(BMI160_FIFO_LENGTH));
> +static IIO_DEVICE_ATTR(hwfifo_enabled, S_IRUGO,
> + bmi160_get_fifo_state, NULL, 0);
> +static IIO_DEVICE_ATTR(hwfifo_watermark, S_IRUGO,
> + bmi160_get_fifo_watermark, NULL, 0);
> +
> +static const struct attribute *bmi160_fifo_attributes[] = {
> + &iio_const_attr_hwfifo_watermark_min.dev_attr.attr,
> + &iio_const_attr_hwfifo_watermark_max.dev_attr.attr,
> + &iio_dev_attr_hwfifo_watermark.dev_attr.attr,
> + &iio_dev_attr_hwfifo_enabled.dev_attr.attr,
> + NULL,
> +};
> +
> +static int bmi160_set_watermark(struct iio_dev *indio_dev, unsigned int val)
> +{
> + struct bmi160_data *data = iio_priv(indio_dev);
> +
> + if (val > BMI160_FIFO_LENGTH)
> + val = BMI160_FIFO_LENGTH;
> +
> + mutex_lock(&data->mutex);
> + data->watermark = val;
This is a little interesting, in that mostly people might expect a
write to the watermark to be immediately applied if it succeeds.
Perhaps protecting with a claim direct mode call (so it faults out if
the buffer is enabled) would give a more consistent userspace interface.
> + mutex_unlock(&data->mutex);
> +
> + return 0;
> +}
> +
> +static int __bmi160_fifo_transfer(struct bmi160_data *data,
> + char *buffer, int num_bytes)
> +{
> + struct regmap *regmap = data->regmap;
> + struct device *dev = regmap_get_device(regmap);
> + size_t step = regmap_get_raw_read_max(regmap);
> + int ret = 0;
> + int i;
> +
> + if (!step || step > num_bytes)
> + step = num_bytes;
> + else if (step < num_bytes)
> + step = data->fifo_sample_size;
> +
> + for (i = 0; i < num_bytes; i += step) {
> + ret = regmap_raw_read(regmap, BMI160_REG_FIFO_DATA,
> + &buffer[i], step);
When it lands, the new regmap repeated read stuff should simplify this
a little. Looks like it missed the recent merge window..
https://patchwork.ozlabs.org/patch/650718/
It's possible the series has died a death as Leonard has move jobs
and gone rather quiet. If anyone fancies chasing up what is happening with
this and perhaps taking over that work that would be great.
> +
> + if (ret)
> + break;
> + }
> +
> + if (ret)
> + dev_err(dev,
> + "Error transferring data from fifo in single steps of %zu\n",
> + step);
> +
> + return ret;
> +}
> +
> +static int __bmi160_fifo_flush(struct iio_dev *indio_dev,
> + unsigned int samples, bool irq)
> +{
> + struct bmi160_data *data = iio_priv(indio_dev);
> + struct regmap *regmap = data->regmap;
> + struct device *dev = regmap_get_device(regmap);
> + int ret;
> + __le16 fifo_length;
> + unsigned int fifo_samples;
> + unsigned int fifo_bytes;
> + u8 *buffer = data->fifo_buffer;
> + u8 *buffer_iter;
> + int64_t last_timestamp, timestamp;
> + unsigned int last_samples;
> + unsigned int i;
> +
> + /* Get the current FIFO length */
> + ret = regmap_bulk_read(regmap, BMI160_REG_FIFO_LENGTH,
> + &fifo_length, sizeof(__le16));
> + if (ret < 0) {
> + dev_err(dev, "Error reading FIFO_LENGTH\n");
> + return ret;
> + }
> +
> + fifo_bytes = le16_to_cpu(fifo_length);
> + fifo_samples = fifo_bytes / data->fifo_sample_size;
> +
> + if (fifo_bytes % data->fifo_sample_size)
> + dev_warn(dev, "fifo_bytes %u is not dividable by %u\n",
> + fifo_bytes, data->fifo_sample_size);
> +
> + if (!fifo_samples)
> + return 0;
> +
> + if (samples && fifo_samples > samples) {
> + fifo_samples = samples;
> + fifo_bytes = fifo_samples * data->fifo_sample_size;
> + }
> +
> + /*
> + * If we are not called from IRQ, it means that we are flushing data
> + * on demand. In that case we do not have latest timestamp saved in
> + * data->timestamp. Get the time now instead.
> + *
> + * In case of IRQ flush, saved timestamp shows the time when number
> + * of samples configured by watermark were ready. Currently there might
> + * be more samples already.
> + * If we are not called from IRQ, than we are getting the current fifo
> + * length, as we are setting timestamp just after getting it.
> + */
> + if (!irq) {
> + last_timestamp = iio_get_time_ns(indio_dev);
> + last_samples = fifo_samples;
> + } else {
> + last_timestamp = data->timestamp;
> + last_samples = data->watermark;
> + }
> +
> + /* Get all measurements */
> + ret = __bmi160_fifo_transfer(data, buffer, fifo_bytes);
> + if (ret)
> + return ret;
> +
> + /* Handle demux */
> + timestamp = last_timestamp - (last_samples * data->fifo_sample_period);
> + buffer_iter = buffer;
> + for (i = 0; i < fifo_samples; i++) {
> + u8 tmp_buf[32];
> +
> + memcpy(tmp_buf, buffer_iter, data->fifo_sample_size);
> +
> + timestamp += data->fifo_sample_period;
> + iio_push_to_buffers_with_timestamp(indio_dev,
> + tmp_buf,
> + timestamp);
> +
> + buffer_iter += data->fifo_sample_size;
> + }
> +
> + return fifo_samples;
> +}
> +
> +static int bmi160_fifo_flush(struct iio_dev *indio_dev, unsigned int samples)
> +{
> + struct bmi160_data *data = iio_priv(indio_dev);
> + int ret;
> +
> + mutex_lock(&data->mutex);
> + ret = __bmi160_fifo_flush(indio_dev, samples, false);
> + mutex_unlock(&data->mutex);
> +
> + return ret;
> +}
> +
> static const struct iio_info bmi160_info = {
> .driver_module = THIS_MODULE,
> .read_raw = bmi160_read_raw,
> @@ -511,6 +983,15 @@ static const struct iio_info bmi160_info = {
> .attrs = &bmi160_attrs_group,
> };
>
> +static const struct iio_info bmi160_info_fifo = {
> + .driver_module = THIS_MODULE,
> + .read_raw = bmi160_read_raw,
> + .write_raw = bmi160_write_raw,
> + .attrs = &bmi160_attrs_group,
> + .hwfifo_set_watermark = bmi160_set_watermark,
> + .hwfifo_flush_to_buffer = bmi160_fifo_flush,
> +};
> +
> static const char *bmi160_match_acpi_device(struct device *dev)
> {
> const struct acpi_device_id *id;
> @@ -572,12 +1053,75 @@ static void bmi160_chip_uninit(struct bmi160_data *data)
> bmi160_set_mode(data, BMI160_ACCEL, false);
> }
>
> +static int bmi160_enable_irq(struct bmi160_data *data)
> +{
> + int ret;
> +
> + mutex_lock(&data->mutex);
> + ret = regmap_update_bits(data->regmap, BMI160_REG_INT_OUT_CTRL,
> + data->irq_data->output_en,
> + data->irq_data->output_en);
> + mutex_unlock(&data->mutex);
> +
> + if (ret == 0)
> + data->irq_enabled = true;
> +
> + return ret;
> +}
> +
> +static int bmi160_disable_irq(struct bmi160_data *data)
> +{
> + int ret;
> +
> + if (!data->irq_enabled)
> + return 0;
> +
> + mutex_lock(&data->mutex);
> + ret = regmap_update_bits(data->regmap, BMI160_REG_INT_OUT_CTRL,
> + data->irq_data->output_en, 0);
> + mutex_unlock(&data->mutex);
> +
> + if (ret == 0)
> + data->irq_enabled = false;
> +
> + return ret;
> +}
> +
> +static irqreturn_t bmi160_irq_thread_handler(int irq, void *p)
> +{
> + struct iio_dev *indio_dev = p;
> + struct bmi160_data *data = iio_priv(indio_dev);
> + struct device *dev = regmap_get_device(data->regmap);
> +
> + mutex_lock(&data->mutex);
> + if (data->fifo_enabled)
> + __bmi160_fifo_flush(indio_dev, BMI160_FIFO_LENGTH, true);
> + else
This is not terribly shared interrupt friendly. We should really be
verifying that the interrupt seen is ours or returning IRQ_NONE otherwise.
Then if we get a load of 'false' interrupts due to hardware issues the
unhandled interrupt stuff in the kernel will deal with it for us.
> + dev_warn(dev,
> + "IRQ has been triggered, but FIFO is not enabled.\n");
> + mutex_unlock(&data->mutex);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t bmi160_irq_handler(int irq, void *p)
> +{
> + struct iio_dev *indio_dev = p;
> + struct bmi160_data *data = iio_priv(indio_dev);
> +
> + data->timestamp = iio_get_time_ns(indio_dev);
> +
> + return IRQ_WAKE_THREAD;
You could use the utility function: iio_pollfunc_store_timestamp
instead of basically replicating it here.
> +}
> +
> int bmi160_core_probe(struct device *dev, struct regmap *regmap,
> - const char *name, bool use_spi)
> + const char *name, int irq,
> + bool use_spi, bool block_supported)
> {
> struct iio_dev *indio_dev;
> struct bmi160_data *data;
> int ret;
> + int irq2;
>
> indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
> if (!indio_dev)
> @@ -585,6 +1129,7 @@ int bmi160_core_probe(struct device *dev, struct regmap *regmap,
>
> data = iio_priv(indio_dev);
> dev_set_drvdata(dev, indio_dev);
> + data->irq = irq;
> data->regmap = regmap;
> mutex_init(&data->mutex);
>
> @@ -603,15 +1148,57 @@ int bmi160_core_probe(struct device *dev, struct regmap *regmap,
> indio_dev->info = &bmi160_info;
>
> ret = iio_triggered_buffer_setup(indio_dev, NULL,
> - bmi160_trigger_handler, NULL);
> + bmi160_trigger_handler,
> + &bmi160_buffer_ops);
> if (ret < 0)
> goto uninit;
>
> + if (data->irq > 0) {
> + /* Check which interrupt pin is connected to our board */
> + irq2 = of_irq_get_byname(dev->of_node, "INT2");
> + if (irq2 == data->irq) {
> + dev_dbg(dev, "Using interrupt line INT2\n");
> + data->irq_data = &bmi160_irq2_data;
> + } else {
> + dev_dbg(dev, "Using interrupt line INT1\n");
> + data->irq_data = &bmi160_irq1_data;
> + }
> +
> + ret = devm_request_threaded_irq(dev,
> + data->irq,
> + bmi160_irq_handler,
> + bmi160_irq_thread_handler,
> + IRQF_ONESHOT,
> + BMI160_IRQ_NAME,
> + indio_dev);
> + if (ret)
> + goto buffer_cleanup;
> +
> + ret = bmi160_enable_irq(data);
> + if (ret < 0)
> + goto buffer_cleanup;
> +
> + if (block_supported) {
> + indio_dev->modes |= INDIO_BUFFER_SOFTWARE;
> + indio_dev->info = &bmi160_info_fifo;
> + indio_dev->buffer->attrs = bmi160_fifo_attributes;
> + data->fifo_buffer = devm_kmalloc(dev,
> + BMI160_FIFO_LENGTH,
> + GFP_KERNEL);
> + if (!data->fifo_buffer) {
> + ret = -ENOMEM;
> + goto disable_irq;
> + }
> + }
> + }
> +
> ret = iio_device_register(indio_dev);
> if (ret < 0)
> - goto buffer_cleanup;
> + goto disable_irq;
>
> return 0;
> +disable_irq:
> + bmi160_disable_irq(data);
> buffer_cleanup:
> iio_triggered_buffer_cleanup(indio_dev);
> uninit:
> @@ -626,6 +1213,7 @@ void bmi160_core_remove(struct device *dev)
> struct bmi160_data *data = iio_priv(indio_dev);
>
> iio_device_unregister(indio_dev);
> + bmi160_disable_irq(data);
> iio_triggered_buffer_cleanup(indio_dev);
> bmi160_chip_uninit(data);
> }
> diff --git a/drivers/iio/imu/bmi160/bmi160_i2c.c b/drivers/iio/imu/bmi160/bmi160_i2c.c
> index 155a31f..1a3f4e1 100644
> --- a/drivers/iio/imu/bmi160/bmi160_i2c.c
> +++ b/drivers/iio/imu/bmi160/bmi160_i2c.c
> @@ -24,6 +24,10 @@ static int bmi160_i2c_probe(struct i2c_client *client,
> {
> struct regmap *regmap;
> const char *name = NULL;
> + bool block_supported =
> + i2c_check_functionality(client->adapter, I2C_FUNC_I2C) ||
> + i2c_check_functionality(client->adapter,
> + I2C_FUNC_SMBUS_READ_I2C_BLOCK);
>
> regmap = devm_regmap_init_i2c(client, &bmi160_regmap_config);
> if (IS_ERR(regmap)) {
> @@ -35,7 +39,8 @@ static int bmi160_i2c_probe(struct i2c_client *client,
> if (id)
> name = id->name;
>
> - return bmi160_core_probe(&client->dev, regmap, name, false);
> + return bmi160_core_probe(&client->dev, regmap, name, client->irq,
> + false, block_supported);
> }
>
> static int bmi160_i2c_remove(struct i2c_client *client)
> diff --git a/drivers/iio/imu/bmi160/bmi160_spi.c b/drivers/iio/imu/bmi160/bmi160_spi.c
> index d34dfdf..5a53225 100644
> --- a/drivers/iio/imu/bmi160/bmi160_spi.c
> +++ b/drivers/iio/imu/bmi160/bmi160_spi.c
> @@ -26,7 +26,8 @@ static int bmi160_spi_probe(struct spi_device *spi)
> (int)PTR_ERR(regmap));
> return PTR_ERR(regmap);
> }
> - return bmi160_core_probe(&spi->dev, regmap, id->name, true);
> + return bmi160_core_probe(&spi->dev, regmap, id->name, spi->irq,
> + true, true);
> }
>
> static int bmi160_spi_remove(struct spi_device *spi)
>
^ permalink raw reply
* Re: [PATCH 7/9] pinctrl: samsung: Add property to mark pad state as suitable for power down
From: Marek Szyprowski @ 2016-12-30 11:55 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-gpio, linux-arm-kernel, linux-pm, linux-samsung-soc,
Sylwester Nawrocki, Linus Walleij, Tomasz Figa, Ulf Hansson,
Bartlomiej Zolnierkiewicz, devicetree
In-Reply-To: <20161227153331.jbh7ei6oh3obmnri@kozik-lap>
Hi Krzysztof,
On 2016-12-27 16:33, Krzysztof Kozlowski wrote:
> On Tue, Dec 27, 2016 at 11:30:57AM +0100, Marek Szyprowski wrote:
>> On 2016-12-25 20:19, Krzysztof Kozlowski wrote:
>>> On Fri, Dec 23, 2016 at 01:24:47PM +0100, Marek Szyprowski wrote:
>>>> Add support for special property "samsung,off-state", which indicates a special
>>>> state suitable for device's "sleep" state. Its pin values/properties should
>>>> match the configuration in power down mode. It indicates that pin controller
>>>> can notify runtime power management subsystem, that it is ready for runtime
>>>> suspend if its all pins are configured for such state. This in turn might
>>>> allow to turn respective power domain off to reduce power consumption.
>>>>
>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>> ---
>>>> Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt | 8 ++++++++
>>>> drivers/pinctrl/samsung/pinctrl-samsung.c | 4 ++++
>>>> drivers/pinctrl/samsung/pinctrl-samsung.h | 1 +
>>>> 3 files changed, 13 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
>>>> index b7bd2e12a269..354eea0e7798 100644
>>>> --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
>>>> +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
>>>> @@ -105,6 +105,7 @@ Required Properties:
>>>> - samsung,pin-drv: Drive strength configuration.
>>>> - samsung,pin-pud-pdn: Pull up/down configuration in power down mode.
>>>> - samsung,pin-drv-pdn: Drive strength configuration in power down mode.
>>>> + - samsung,off-state: Mark this configuration as suitable for bank power off.
>>>> The values specified by these config properties should be derived from the
>>>> hardware manual and these values are programmed as-is into the pin
>>>> @@ -113,6 +114,13 @@ Required Properties:
>>>> Note: A child should include atleast a pin function selection property or
>>>> pin configuration property (one or more) or both.
>>>> + Note: Special property "samsung,off-state" indicates that this state can
>>>> + be used for device's "sleep" pins state. Its pin values/properties should
>>>> + match the configuration in power down mode.
>>> Why power down values cannot be used for sleep state? Why you need
>>> separate pin control state? If pins values should match power down
>>> configuration, then they could just be added to default state, couldn't
>>> they?
>> Separate sleep state is needed because of the pin control bindings and
>> design.
>>
>> A separate sleep state is required to let pin control client driver (in this
>> case
>> Exynos I2S driver) let to choose when it is okay to switch pads into sleep
>> state and I see no other way to achieve this.
> Maybe the pinctrl API should be extended for this? Doing this in DTS
> just for purpose of passing information between drivers (consumer and
> provider) looks odd.
Well, I don't know if it is odd or not, but that's how it is used now
and I see
no reason to reinvent wheel. Please check it yourself:
$ git grep \"sleep\" arch/arm/boot/dts | wc -l
101
> Anyway, you are proposing a new binding so please Cc devicetree mailing
> list and device tree maintainers.
I'm just using the generic pinctrl bindings, but it might make some sense to
add a note to Exynos i2s driver that a sleep pin control state is needed if
one wants to get power domain to be turned off.
>>> In the patch 2/9, existing configuration:
>>> 716 i2s0_bus: i2s0-bus {
>>> (...)
>>> 719 samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
>>> 720 samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
>>> 721 samsung,pin-drv = <EXYNOS5420_PIN_DRV_LV1>;
>>> 722 };
>>>
>>> additional configuration:
>>> + i2s0_bus_slp: i2s0-bus-slp {
>>> + samsung,pin-function = <EXYNOS_PIN_FUNC_INPUT>;
>>> + samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
>>> + samsung,pin-drv = <EXYNOS5420_PIN_DRV_LV1>;
>>> + samsung,pin-con-pdn = <EXYNOS_PIN_PDN_INPUT>;
>>> + samsung,pin-pud-pdn = <EXYNOS_PIN_PULL_NONE>;
>>> + samsung,off-state;
>>> + };
>> I agree that it would be possible to get rid of "samsung,off-state" property
>> and
>> just detect off state when func/pud pair matches power down func/pud.
>>
>>>> It indicates that pin control
>>>> + can notify runtime power management subsystem, that it is ready for runtime
>>>> + suspend if its all pins are configured for such state. This in turn might
>>>> + allow to turn respective power domain off to reduce power consumption.
>>> What do you mean by "notifying RPM subsystem"? Either this is
>>> description of hardware in certain mode (sleep state) or this is not
>>> device tree property.
>> Maybe I wrote the description with a view too limited to the kernel
>> operation
>> perspective, but if we remove the need to mark state as off, the above
>> description
>> will not be needed.
> But still it wouldn't be describing any hardware property, would it?
Well, it somehow describes the hardware, because the pin state when it
is allowed
to turn off the power domain is board specific. I should move that part
to the
Odroid dts, because there might be a board which require other pin
values in power
down mode.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [PATCH 2/2] ARM: imx: Add speed grading check for imx6ul
From: Shawn Guo @ 2016-12-30 11:57 UTC (permalink / raw)
To: Bai Ping
Cc: kernel-bIcnvbaLZ9MEGnE8C9+IrQ, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, fabio.estevam-3arQi8VN3Tc,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1480475098-2037-2-git-send-email-ping.bai-3arQi8VN3Tc@public.gmane.org>
On Wed, Nov 30, 2016 at 11:04:58AM +0800, Bai Ping wrote:
> On i.MX6UL, it has two type of part, the difference
> is the max ARM frequency that can run at(528MHz/700MHz).
> The part can be identified by part marking for speed grading
> fuse. This patch add speed grading check to disable the unsupported
> OPP dynamically.
>
> Signed-off-by: Bai Ping <ping.bai-3arQi8VN3Tc@public.gmane.org>
We chose to handle such speed grading thing in IMX platform code with
the assumption that this is a special case for i.MX6Q only. No, I'm not
going to take such code for any other i.MX6 SoCs. Please patch cpufreq
driver to handle the speed grading check.
Shawn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/2] Use macros to describe gpios on rockchip platform
From: Heiko Stuebner @ 2016-12-30 12:31 UTC (permalink / raw)
To: Andy Yan
Cc: linux-kernel, linux-rockchip, devicetree, robh+dt, mark.rutland,
linux, linux-arm-kernel
In-Reply-To: <1477140706-6886-1-git-send-email-andy.yan@rock-chips.com>
Am Samstag, 22. Oktober 2016, 20:51:46 CET schrieb Andy Yan:
> As patch 150696e2e3a4("Add GPIO pin index definition for rockchip pinctrl")
> has been applied, now we can use these macros to describe the corresponding
> gpio ranther than hard code numbers, this will make the dts easier to read
> and write.
>
> Some ideas from Krzysztof's patch on EXYNOS[0].
>
> [0]https://lkml.org/lkml/2016/9/4/71
>
>
>
> Andy Yan (2):
> ARM: dts: rockchip: use pin constants to describe gpios
> ARM64: dts: rockchip: use pin constants to describe gpios
applied to dts branches for 4.11
I've also adapted the gpio interrupts accordingly inside the patches.
Thanks
Heiko
^ permalink raw reply
* [PATCH] net: stmmac: remove unused duplicate property snps,axi_all
From: Niklas Cassel @ 2016-12-30 12:56 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Giuseppe Cavallaro, Alexandre Torgue,
David S. Miller, Eric Engestrom, Gabriel Fernandez,
Joachim Eastwood, Vincent Palatin
Cc: Niklas Cassel, netdev, devicetree, linux-kernel
From: Niklas Cassel <niklas.cassel@axis.com>
For core revision 3.x Address-Aligned Beats is available in two registers.
The DT property snps,aal was created for AAL in the DMA bus register,
which is a read/write bit.
The DT property snps,axi_all was created for AXI_AAL in the AXI bus mode
register, which is a read only bit that reflects the value of AAL in the
DMA bus register.
Since the value of snps,axi_all is never used in the driver,
and since the property was created for a bit that is read only,
it should be safe to remove the property.
Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
---
Documentation/devicetree/bindings/net/stmmac.txt | 1 -
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 1 -
include/linux/stmmac.h | 1 -
3 files changed, 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
index 128da752fec9..c3d2fd480a1b 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -65,7 +65,6 @@ Optional properties:
- snps,wr_osr_lmt: max write outstanding req. limit
- snps,rd_osr_lmt: max read outstanding req. limit
- snps,kbbe: do not cross 1KiB boundary.
- - snps,axi_all: align address
- snps,blen: this is a vector of supported burst length.
- snps,fb: fixed-burst
- snps,mb: mixed-burst
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 082cd48db6a7..60ba8993c650 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -121,7 +121,6 @@ static struct stmmac_axi *stmmac_axi_setup(struct platform_device *pdev)
axi->axi_lpi_en = of_property_read_bool(np, "snps,lpi_en");
axi->axi_xit_frm = of_property_read_bool(np, "snps,xit_frm");
axi->axi_kbbe = of_property_read_bool(np, "snps,axi_kbbe");
- axi->axi_axi_all = of_property_read_bool(np, "snps,axi_all");
axi->axi_fb = of_property_read_bool(np, "snps,axi_fb");
axi->axi_mb = of_property_read_bool(np, "snps,axi_mb");
axi->axi_rb = of_property_read_bool(np, "snps,axi_rb");
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 266dab9ad782..889e0e9a3f1c 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -103,7 +103,6 @@ struct stmmac_axi {
u32 axi_wr_osr_lmt;
u32 axi_rd_osr_lmt;
bool axi_kbbe;
- bool axi_axi_all;
u32 axi_blen[AXI_BLEN];
bool axi_fb;
bool axi_mb;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 2/3] ARM: dts: imx6ul: Add OCOTP node
From: Shawn Guo @ 2016-12-30 13:01 UTC (permalink / raw)
To: Daniel Schultz
Cc: mark.rutland, devicetree, Bai Ping, robh+dt, srinivas.kandagatla,
kernel, fabio.estevam, maxime.ripard, linux-arm-kernel
In-Reply-To: <1480689949-17957-2-git-send-email-d.schultz@phytec.de>
On Fri, Dec 02, 2016 at 03:45:48PM +0100, Daniel Schultz wrote:
> This device node adds OCOTP for the i.MX6UL SoC.
>
> Signed-off-by: Daniel Schultz <d.schultz@phytec.de>
Bai Ping (Cc'ed here) from NXP is sending similar patches [1]. DTS
change looks good to me, but I will not apply it until the driver and
bindings get accepted.
Shawn
[1] https://www.spinics.net/lists/arm-kernel/msg540900.html
> ---
> arch/arm/boot/dts/imx6ul.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
> index c5c05fd..ee53795 100644
> --- a/arch/arm/boot/dts/imx6ul.dtsi
> +++ b/arch/arm/boot/dts/imx6ul.dtsi
> @@ -849,6 +849,12 @@
> reg = <0x021b0000 0x4000>;
> };
>
> + ocotp: ocotp@021bc000 {
> + compatible = "fsl,imx6ul-ocotp";
> + reg = <0x021bc000 0x4000>;
> + clocks = <&clks IMX6UL_CLK_OCOTP>;
> + };
> +
> lcdif: lcdif@021c8000 {
> compatible = "fsl,imx6ul-lcdif", "fsl,imx28-lcdif";
> reg = <0x021c8000 0x4000>;
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] iio: misc: add support for GPIO power switches
From: Linus Walleij @ 2016-12-30 13:05 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Bartosz Golaszewski, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Rob Herring,
Mark Rutland, linux-iio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Kevin Hilman, Patrick Titiano, Neil Armstrong, Alexandre Courbot,
linux-gpio@vger.kernel.org, linux-pm@vger.kernel.org, Mark Brown,
Lia
In-Reply-To: <20161229162919.j2ej2cyeuoqnxykf@earth>
n Thu, Dec 29, 2016 at 5:29 PM, Sebastian Reichel <sre@kernel.org> wrote:
> On Wed, Dec 28, 2016 at 01:50:17PM +0100, Linus Walleij wrote:
>> On Sun, Dec 11, 2016 at 11:21 PM, Bartosz Golaszewski
>> <bgolaszewski@baylibre.com> wrote:
>>
>> > Some power-measuring ADCs work together with power load switches which
>> > allow to power-cycle measured devices.
>> >
>> > An example use case would be measuring the power consumption of a
>> > development board during boot using a power monitor such as TI INA226
>> > and power-cycling the board remotely using a TPS229* power switch.
>> >
>> > Add an iio driver for simple GPIO power switches and expose a sysfs
>> > attribute allowing to toggle their state.
>> >
>> > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> I don't get this, isn't this doing the same as
>> drivers/power/reset/gpio-poweroff.c
>> ?
>>
>> With the only difference that the latter uses the standard syscall
>> from pm_power_off to reboot the system instead of some random
>> sysfs file.
>
> As far as I understand it, the TPS229 is used by Barzosz to poweroff
> a remote system. The gpio-poweroff driver is used to poweroff the
> local system.
Thanks yeah I understood this from the context of later patches.
Well if such a property is used it should be the property of the remote
system per se, and the remote system should then also be desribed in
DT, not half-described by dangling references at random nodes.
So this needs to be re-architected to either describe the remote system
in DT and handle it in the kernel, or handle it all from userspace if it
is a one-off non-product thing.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 10/20] gpio: pca953x: Add optional reset gpio control
From: Linus Walleij @ 2016-12-30 13:17 UTC (permalink / raw)
To: Steve Longerbeam
Cc: Shawn Guo, Sascha Hauer, Fabio Estevam, Rob Herring, Mark Rutland,
Russell King, Alexandre Courbot, Mauro Carvalho Chehab, Greg KH,
Philipp Zabel, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-media@vger.kernel.org,
devel@driverdev.osuosl.org
In-Reply-To: <1483050455-10683-11-git-send-email-steve_longerbeam@mentor.com>
On Thu, Dec 29, 2016 at 11:27 PM, Steve Longerbeam
<slongerbeam@gmail.com> wrote:
> Add optional reset-gpios pin control. If present, de-assert the
> specified reset gpio pin to bring the chip out of reset.
>
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Alexandre Courbot <gnurou@gmail.com>
> Cc: linux-gpio@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
This seems like a separate patch from the other 19 patches so please send it
separately so I can handle logistics easier in the future.
> @@ -133,6 +134,7 @@ struct pca953x_chip {
> const char *const *names;
> unsigned long driver_data;
> struct regulator *regulator;
> + struct gpio_desc *reset_gpio;
Why do you even keep this around in the device state container?
As you only use it in the probe() function, use a local variable.
The descriptor will be free():ed by the devm infrastructure anyways.
> + /* see if we need to de-assert a reset pin */
> + chip->reset_gpio = devm_gpiod_get_optional(&client->dev,
> + "reset",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(chip->reset_gpio)) {
> + dev_err(&client->dev, "request for reset pin failed\n");
> + return PTR_ERR(chip->reset_gpio);
> + }
Nice.
> + if (chip->reset_gpio) {
> + /* bring chip out of reset */
> + dev_info(&client->dev, "releasing reset\n");
> + gpiod_set_value(chip->reset_gpio, 0);
> + }
Is this really needed given that you set it low in the
devm_gpiod_get_optional()?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 1/4] pinctrl: samsung: Fix the width of PINCFG_TYPE_DRV bitfields for Exynos5433
From: Linus Walleij @ 2016-12-30 13:28 UTC (permalink / raw)
To: Andi Shyti
Cc: Chanwoo Choi, Tomasz Figa, Krzysztof Kozlowski,
Sylwester Nawrocki, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Kukjin Kim, Javier Martinez Canillas,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-samsung-soc, linux-kernel@vger.kernel.org, stable,
Andi Shyti
In-Reply-To: <20161230041421.24448-2-andi.shyti@samsung.com>
On Fri, Dec 30, 2016 at 5:14 AM, Andi Shyti <andi.shyti@samsung.com> wrote:
> From: Chanwoo Choi <cw00.choi@samsung.com>
>
> This patch fixes the wrong width of PINCFG_TYPE_DRV bitfields for Exynos5433
> because PINCFG_TYPE_DRV of Exynos5433 has 4bit fields in the *_DRV
> registers. Usually, other Exynos have 2bit field for PINCFG_TYPE_DRV.
>
> Fixes: 3c5ecc9ed353 ("pinctrl: exynos: Add support for Exynos5433")
> Cc: stable@vger.kernel.org
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Nominally I think you should sign this off too Andi, as you are in the delivery
path.
Patch applied for fixes.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 2/4] pinctrl: dt-bindings: samsung: add drive strength macros for Exynos5433
From: Linus Walleij @ 2016-12-30 13:30 UTC (permalink / raw)
To: Andi Shyti
Cc: Chanwoo Choi, Tomasz Figa, Krzysztof Kozlowski,
Sylwester Nawrocki, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Kukjin Kim, Javier Martinez Canillas,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-samsung-soc,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, stable,
Andi Shyti
In-Reply-To: <20161230041421.24448-3-andi.shyti-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Fri, Dec 30, 2016 at 5:14 AM, Andi Shyti <andi.shyti-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
> Commit 5db7e3bb87df ("pinctrl: dt-bindings: samsung: Add header with
> values used for configuration") has added a header file for defining the
> pinctrl values in order to avoid hardcoded settings in the Exynos
> DTS related files.
>
> Extend samsung.h to the Exynos5433 for drive strength values
> which are strictly related to the particular SoC and may defer
> from others.
>
> Signed-off-by: Andi Shyti <andi.shyti-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Patch applied with Chanwoo's review tag.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/4] ARM64: dts: exynos5433: use macros for pinctrl configuration on Exynos5433
From: Linus Walleij @ 2016-12-30 13:32 UTC (permalink / raw)
To: Andi Shyti
Cc: Chanwoo Choi, Tomasz Figa, Krzysztof Kozlowski,
Sylwester Nawrocki, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Kukjin Kim, Javier Martinez Canillas,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-samsung-soc, linux-kernel@vger.kernel.org, stable,
Andi Shyti
In-Reply-To: <20161230041421.24448-4-andi.shyti@samsung.com>
On Fri, Dec 30, 2016 at 5:14 AM, Andi Shyti <andi.shyti@samsung.com> wrote:
> Use the macros defined in include/dt-bindings/pinctrl/samsung.h
> instead of hardcoded values.
>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
These look fine, but that this and the other DTS patch through ARM SoC.
If you also need the headerfile patch (patch 2) to go through ARM SoC
that is fine,
I can take it out of pinctrl if you want.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 0/5] ARM: dts: boundary: remove hardcoded LVDS bus format
From: Shawn Guo @ 2016-12-30 13:37 UTC (permalink / raw)
To: Gary Bisson
Cc: fabio.estevam-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161202090843.22613-1-gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
On Fri, Dec 02, 2016 at 10:08:38AM +0100, Gary Bisson wrote:
> Gary Bisson (5):
> ARM: dts: imx6qdl-nit6xlite: remove hardcoded LVDS bus format
> ARM: dts: imx6qdl-nitrogen6_max: remove hardcoded LVDS bus format
> ARM: dts: imx6qdl-nitrogen6_som2: remove hardcoded LVDS bus format
> ARM: dts: imx6qdl-nitrogen6x: remove hardcoded LVDS bus format
> ARM: dts: imx6qdl-sabrelite: remove hardcoded LVDS bus format
I squashed them and applied, thanks.
Shawn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
From: Neil Armstrong @ 2016-12-30 13:40 UTC (permalink / raw)
To: heinrich.schuchardt-Mmb7MZpHnFY, khilman-rdvid1DuHRBWk0Htik3J/w,
carlo-KA+7E9HrN00dnm+yROfE0A
Cc: Neil Armstrong, linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
this patch adds this reserved zone and redefines the usable memory range.
Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
Changes since v1 at [1] :
- Renamed reg into linux,usable-memory to ovveride u-boot memory
- only kept secmon memory zone
[1] http://lkml.kernel.org/r/20161212101801.28491-1-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org
arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 2 +-
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 12 ++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 2 +-
11 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
index 7a078be..ca3c7fa 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
@@ -56,7 +56,7 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
vddio_boot: regulator-vddio_boot {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index eada0b5..7f244b5 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -55,6 +55,18 @@
#address-cells = <2>;
#size-cells = <2>;
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* global autoconfigured region for contiguous allocations */
+ secmon: secmon {
+ reg = <0x0 0x10000000 0x0 0x200000>;
+ no-map;
+ };
+ };
+
cpus {
#address-cells = <0x2>;
#size-cells = <0x0>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
index 4cbd626..c7f008a 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
@@ -62,7 +62,7 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x40000000>;
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
};
leds {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 238fbea..546cbe4 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -61,7 +61,7 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
usb_otg_pwr: regulator-usb-pwrs {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 4a96e0f..1fdf6da 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -55,7 +55,7 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x40000000>;
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
};
usb_pwr: regulator-usb-pwrs {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
index 62fb496..6ac5c89 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
@@ -50,6 +50,6 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
index 9a9663a..58be8b4 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
@@ -50,6 +50,6 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x40000000>;
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
index 2fe167b..010cb29 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
@@ -50,6 +50,6 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
index cea4a3e..fb4a89b 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
@@ -60,7 +60,7 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
vddio_card: gpio-regulator {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
index 9639f01..908894c 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
@@ -59,7 +59,7 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
index 5a337d3..2077385 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
@@ -62,7 +62,7 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
vddio_boot: regulator-vddio-boot {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 1/5] pinctrl: core: Use delayed work for hogs
From: Linus Walleij @ 2016-12-30 13:46 UTC (permalink / raw)
To: Tony Lindgren
Cc: Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Linux-OMAP
In-Reply-To: <20161227172003.6517-2-tony@atomide.com>
On Tue, Dec 27, 2016 at 6:19 PM, Tony Lindgren <tony@atomide.com> wrote:
> Having the pin control framework call pin controller functions
> before it's probe has finished is not nice as the pin controller
> device driver does not yet have struct pinctrl_dev handle.
> Let's fix this issue by adding deferred work for late init. This is
> needed to be able to add pinctrl generic helper functions that expect
> to know struct pinctrl_dev handle. Note that we now need to call
> create_pinctrl() directly as we don't want to add the pin controller
> to the list of controllers until the hogs are claimed. We also need
> to pass the pinctrl_dev to the device tree parser functions as they
> otherwise won't find the right controller at this point.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
Patch applied.
I felt the code path needed some extra comments so I sent those
as a separate patch.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 3/5] pinctrl: core: Add generic pinctrl functions for managing groups
From: Linus Walleij @ 2016-12-30 14:09 UTC (permalink / raw)
To: Tony Lindgren
Cc: Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Linux-OMAP
In-Reply-To: <20161227172003.6517-4-tony@atomide.com>
On Tue, Dec 27, 2016 at 6:20 PM, Tony Lindgren <tony@atomide.com> wrote:
> We can add generic helpers for function handling for cases where the pin
> controller driver does not need to use static arrays.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
Patch applied!
> +config GENERIC_PINMUX
> + bool
> + select PINMUX
I applied the first that had GENERIC_PINCTRL instead,
Then I went in and renamed this GENERIC_PINCTRL_GROUPS
since that is what it's all about.
Sent out as separate patch!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 2/5] pinctrl: core: Add generic pinctrl functions for managing groups
From: Linus Walleij @ 2016-12-30 14:12 UTC (permalink / raw)
To: Tony Lindgren
Cc: Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-OMAP
In-Reply-To: <20161227172003.6517-3-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
On Tue, Dec 27, 2016 at 6:20 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> We can add generic helpers for pin group handling for cases where the pin
> controller driver does not need to use static arrays.
>
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Patch applied.
> +config GENERIC_PINCTRL
> + bool
Then I renamed *this* to GENERIC_PINCTRL_GROUPS.
(Not the other patch, I got confused because gmail threads the
second and third patch together, sorry.)
Let's see if I manage to rebase the next patch on this.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx6q-utilite-pro: enable 2nd display pipeline
From: Shawn Guo @ 2016-12-30 14:27 UTC (permalink / raw)
To: christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ
Cc: kernel-bIcnvbaLZ9MEGnE8C9+IrQ, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
grinberg-UTxiZqZC01RS1MOuV/RT9w, fabio.estevam-3arQi8VN3Tc
In-Reply-To: <ec9676f344eb4786a28a3c7b969f0e94-gtPewvpZjL8umhiu9RXYRl5UTUQ924AY@public.gmane.org>
On Fri, Dec 02, 2016 at 03:37:22PM +0100, christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org wrote:
> From: Christopher Spinrath <christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org>
>
> Apart from the already enabled Designware HDMI port, the Utilite Pro
> has a second display pipeline which has the following shape:
>
> IPU1 DI0 --> Parallel display --> tfp410 rgb24 to DVI encoder
> --> HDMI connector.
> Enable support for it.
>
> In addition, since this pipeline is hardwired to IPU1, sever the link
> between IPU1 and the SoC-internal Designware HDMI encoder forcing the
> latter to be connected to IPU2 instead of IPU1. Otherwise, it is not
> possible to drive both displays at high resolution due to the bandwidth
> limitations of a single IPU.
>
> Signed-off-by: Christopher Spinrath <christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org>
@Philipp, can you help review the changes?
> ---
>
> Hi all,
>
> the removal of the link between IPU1 and the Designware HDMI encoder is the
> result of a discussion I had with Philipp Zabel:
>
> https://lists.freedesktop.org/archives/dri-devel/2016-November/125399.html .
>
> Altough it is not possible to connect anything else to IPU1 on the Utilite, this
> approach has at least one disadvantage: if the resolution is low enough such
> that a single IPU can handle both displays then muxing both displays to IPU1
> would reduce the power consumption.
>
> However, IMHO omitting the link IPU1 <--> DW HDMI is still the preferrable
> solution since I'm not aware of any OS/driver that is capable of switching IPUs
> or can handle the bandwidth limitation in a sane way. In particular, Linux is
> unusable when both displays are supposed to be driven at high resolution and
> both muxing options for the DW HDMI are available (this is not a userspace
> issue; the system becomes almost unresponsive as soon as the kernel sets the
> initial resolution).
>
> Cheers,
> Christopher
>
> P.S.: this patch depends on the tfp410 bridge driver which has recently been
> merged into drm-next.
v4.10-rc1 has the driver, so the dependency is gone now, I guess.
>
> arch/arm/boot/dts/imx6q-utilite-pro.dts | 115 ++++++++++++++++++++++++++++++++
> 1 file changed, 115 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6q-utilite-pro.dts b/arch/arm/boot/dts/imx6q-utilite-pro.dts
> index 2200994..69bdd82 100644
> --- a/arch/arm/boot/dts/imx6q-utilite-pro.dts
> +++ b/arch/arm/boot/dts/imx6q-utilite-pro.dts
> @@ -59,6 +59,33 @@
> rtc1 = &snvs_rtc;
> };
>
> + encoder {
> + compatible = "ti,tfp410";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + tfp410_in: endpoint {
> + remote-endpoint = <¶llel_display_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + tfp410_out: endpoint {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> + };
> + };
> + };
> +
> gpio-keys {
> compatible = "gpio-keys";
> pinctrl-names = "default";
> @@ -72,6 +99,19 @@
> };
> };
>
> + hdmi-connector {
> + compatible = "hdmi-connector";
> +
The newline is unnecessary.
> + type = "a";
> + ddc-i2c-bus = <&i2c_dvi_ddc>;
> +
> + port {
> + hdmi_connector_in: endpoint {
> + remote-endpoint = <&tfp410_out>;
> + };
> + };
> + };
> +
> i2cmux {
> compatible = "i2c-mux-gpio";
> pinctrl-names = "default";
> @@ -105,8 +145,46 @@
> #size-cells = <0>;
> };
> };
> +
> + parallel-display {
> + compatible = "fsl,imx-parallel-display";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ipu1>;
> +
Ditto
I can fix them up if I get a Reviewed-by tag from Philipp on this
version.
Shawn
> + interface-pix-fmt = "rgb24";
> +
> + port@0 {
> + reg = <0>;
> +
> + parallel_display_in: endpoint {
> + remote-endpoint = <&ipu1_di0_disp0>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + parallel_display_out: endpoint {
> + remote-endpoint = <&tfp410_in>;
> + };
> + };
> + };
> };
>
> +/*
> + * A single IPU is not able to drive both display interfaces available on the
> + * Utilite Pro at high resolution due to its bandwidth limitation. Since the
> + * tfp410 encoder is wired up to IPU1, sever the link between IPU1 and the
> + * SoC-internal Designware HDMI encoder forcing the latter to be connected to
> + * IPU2 instead of IPU1.
> + */
> +/delete-node/&ipu1_di0_hdmi;
> +/delete-node/&hdmi_mux_0;
> +/delete-node/&ipu1_di1_hdmi;
> +/delete-node/&hdmi_mux_1;
> +
> &hdmi {
> ddc-i2c-bus = <&i2c2>;
> status = "okay";
> @@ -151,6 +229,39 @@
> >;
> };
>
> + pinctrl_ipu1: ipu1grp {
> + fsl,pins = <
> + MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x38
> + MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15 0x38
> + MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02 0x38
> + MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03 0x38
> + MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00 0x38
> + MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01 0x38
> + MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02 0x38
> + MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03 0x38
> + MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04 0x38
> + MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05 0x38
> + MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06 0x38
> + MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07 0x38
> + MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08 0x38
> + MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09 0x38
> + MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10 0x38
> + MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11 0x38
> + MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12 0x38
> + MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13 0x38
> + MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14 0x38
> + MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 0x38
> + MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 0x38
> + MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17 0x38
> + MX6QDL_PAD_DISP0_DAT18__IPU1_DISP0_DATA18 0x38
> + MX6QDL_PAD_DISP0_DAT19__IPU1_DISP0_DATA19 0x38
> + MX6QDL_PAD_DISP0_DAT20__IPU1_DISP0_DATA20 0x38
> + MX6QDL_PAD_DISP0_DAT21__IPU1_DISP0_DATA21 0x38
> + MX6QDL_PAD_DISP0_DAT22__IPU1_DISP0_DATA22 0x38
> + MX6QDL_PAD_DISP0_DAT23__IPU1_DISP0_DATA23 0x38
> + >;
> + };
> +
> pinctrl_uart2: uart2grp {
> fsl,pins = <
> MX6QDL_PAD_GPIO_7__UART2_TX_DATA 0x1b0b1
> @@ -194,6 +305,10 @@
> };
> };
>
> +&ipu1_di0_disp0 {
> + remote-endpoint = <¶llel_display_in>;
> +};
> +
> &pcie {
> pcie@0,0 {
> reg = <0x000000 0 0 0 0>;
> --
> 2.10.2
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/5] pinctrl: core: Add generic pinctrl functions for managing groups
From: Linus Walleij @ 2016-12-30 14:28 UTC (permalink / raw)
To: Tony Lindgren
Cc: Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-OMAP
In-Reply-To: <20161227172003.6517-4-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
On Tue, Dec 27, 2016 at 6:20 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> We can add generic helpers for function handling for cases where the pin
> controller driver does not need to use static arrays.
>
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Patch applied.
> +config GENERIC_PINMUX
> + bool
> + select PINMUX
I renamed this GENERIC_PINMUX_FUNCTIONS
> + INIT_RADIX_TREE(&pctldev->pin_function_tree, GFP_KERNEL);
#ifdefed this
> + struct radix_tree_root pin_function_tree;
> unsigned int num_groups;
> + unsigned int num_functions;
#ifdefed these
> /**
> + * struct function_desc - generic function descriptor
> + * @name: name of the function
> + * @group_names: array of pin group names
> + * @num_group_names: number of pin group names
> + * @data: pin controller driver specific data
> + */
> +struct function_desc {
> + const char *name;
> + const char **group_names;
> + int num_group_names;
> + void *data;
> +};
And moved this into pinmux.h
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 4/5] pinctrl: single: Use generic pinctrl helpers for managing groups
From: Linus Walleij @ 2016-12-30 14:32 UTC (permalink / raw)
To: Tony Lindgren
Cc: Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Linux-OMAP
In-Reply-To: <20161227172003.6517-5-tony@atomide.com>
On Tue, Dec 27, 2016 at 6:20 PM, Tony Lindgren <tony@atomide.com> wrote:
> We can now drop the driver specific code for managing groups.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
Patch applied!
> + select GENERIC_PINCTRL
Replaced this with GENERIC_PINCTRL_GROUPS
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 5/5] pinctrl: single: Use generic pinmux helpers for managing functions
From: Linus Walleij @ 2016-12-30 14:35 UTC (permalink / raw)
To: Tony Lindgren
Cc: Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-OMAP
In-Reply-To: <20161227172003.6517-6-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
On Tue, Dec 27, 2016 at 6:20 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> We can now drop the driver specific code for managing functions.
>
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Patch applied.
> - select PINMUX
> + select GENERIC_PINMUX
Replaced this with GENERIC_PINMUX_FUNCTIONS
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v7 3/5] ARM: dts: stm32: Add I2C1 support for STM32F429 SoC
From: M'boumba Cedric Madianga @ 2016-12-30 14:36 UTC (permalink / raw)
To: Linus Walleij
Cc: Uwe Kleine-König, Wolfram Sang, Rob Herring, Maxime Coquelin,
Alexandre Torgue, Patrice Chotard, Russell King,
linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CACRpkdaNyL2iV+risLudW=O55w81-AuEZhMwRu9NLdXpnC2r1w@mail.gmail.com>
Hi Linus,
2016-12-30 10:07 GMT+01:00 Linus Walleij <linus.walleij@linaro.org>:
> On Fri, Dec 23, 2016 at 2:09 PM, M'boumba Cedric Madianga
> <cedric.madianga@gmail.com> wrote:
>> 2016-12-22 20:11 GMT+01:00 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
>>> On Thu, Dec 22, 2016 at 02:35:02PM +0100, M'boumba Cedric Madianga wrote:
>>>> @@ -337,6 +350,16 @@
>>>> slew-rate = <2>;
>>>> };
>>>> };
>>>> +
>>>> + i2c1_pins_b: i2c1@0 {
>>>> + pins1 {
>>>> + pinmux = <STM32F429_PB9_FUNC_I2C1_SDA>;
>>>> + drive-open-drain;
>>>> + };
>>>> + pins2 {
>>>> + pinmux = <STM32F429_PB6_FUNC_I2C1_SCL>;
>>>> + };
>>>
>>> the second doesn't need the open-drain property? Why?
>>
>> I thought that open-drain was only needed for SDA line.
>> But after double-checking I2C specification, it seems that SDA and SCL
>> lines need open-drain or open-collector to perform the wired-AND
>> function.
>
> I think I2C SDA/SCL must be open drain by definition.
>
> It also requires pull-up resistors, I guess you have these mounted on the board
> so you do not need pull-up from the pin controller?
Yes, I have 1 pull-up resistor of 1,5K ohm for each line (SDA & SCL)
on the board
>
> Yours,
> Linus Walleij
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox