RE: [PATCH] mfd: tps65910: Select REGMAP_IRQ in Kconfig to fix build error
On Wed, Jan 09, 2013 at 22:22:35, Porter, Matt wrote: > On Wed, Jan 02, 2013 at 10:15:39AM +, AnilKumar wrote: > > On Mon, Dec 10, 2012 at 16:44:56, AnilKumar, Chimata wrote: > > > TPS65910 mfd driver uses functions that are only avaiable when > > > REGMAP_IRQ is enabled. So "select REGMAP_IRQ" is added to mfd > > > Kconfig to fix below build error: > > > > > > drivers/built-in.o: In function `tps65910_irq_exit': > > > /media/anil/kernel/drivers/mfd/tps65910.c:265: undefined reference to > > > `regmap_del_irq_chip' > > > drivers/built-in.o: In function `tps65910_irq_init': > > > /media/anil/kernel/drivers/mfd/tps65910.c:254: undefined reference to > > > `regmap_add_irq_chip' > > > drivers/built-in.o: In function `tps65910_i2c_probe': > > > /media/anil/kernel/drivers/mfd/tps65910.c:509: undefined reference to > > > `regmap_irq_get_domain' > > > make: *** [vmlinux] Error 1 > > > > > > Signed-off-by: AnilKumar Ch > > > --- > > > drivers/mfd/Kconfig |1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > > > index 1c0abd4..01413a2 100644 > > > --- a/drivers/mfd/Kconfig > > > +++ b/drivers/mfd/Kconfig > > > @@ -237,6 +237,7 @@ config MFD_TPS65910 > > > depends on I2C=y && GPIOLIB > > > select MFD_CORE > > > select REGMAP_I2C > > > + select REGMAP_IRQ > > > select IRQ_DOMAIN > > > help > > > if you say yes here you get support for the TPS65910 series of > > > > Hi Samuel, > > > > Could you please pull this fix? > > Tested-by: Matt Porter > > Fixes broken OMAP kernel build here too. > Hi Samuel, Could you please take this in? Thanks AnilKumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] mfd: tps65910: Select REGMAP_IRQ in Kconfig to fix build error
On Mon, Dec 10, 2012 at 16:44:56, AnilKumar, Chimata wrote: > TPS65910 mfd driver uses functions that are only avaiable when > REGMAP_IRQ is enabled. So "select REGMAP_IRQ" is added to mfd > Kconfig to fix below build error: > > drivers/built-in.o: In function `tps65910_irq_exit': > /media/anil/kernel/drivers/mfd/tps65910.c:265: undefined reference to > `regmap_del_irq_chip' > drivers/built-in.o: In function `tps65910_irq_init': > /media/anil/kernel/drivers/mfd/tps65910.c:254: undefined reference to > `regmap_add_irq_chip' > drivers/built-in.o: In function `tps65910_i2c_probe': > /media/anil/kernel/drivers/mfd/tps65910.c:509: undefined reference to > `regmap_irq_get_domain' > make: *** [vmlinux] Error 1 > > Signed-off-by: AnilKumar Ch > --- > drivers/mfd/Kconfig |1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index 1c0abd4..01413a2 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -237,6 +237,7 @@ config MFD_TPS65910 > depends on I2C=y && GPIOLIB > select MFD_CORE > select REGMAP_I2C > + select REGMAP_IRQ > select IRQ_DOMAIN > help > if you say yes here you get support for the TPS65910 series of Hi Samuel, Could you please pull this fix? Thanks AnilKumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] mfd: tps65910: Select REGMAP_IRQ in Kconfig to fix build error
On Mon, Dec 10, 2012 at 16:44:56, AnilKumar, Chimata wrote: > TPS65910 mfd driver uses functions that are only avaiable when > REGMAP_IRQ is enabled. So "select REGMAP_IRQ" is added to mfd > Kconfig to fix below build error: > > drivers/built-in.o: In function `tps65910_irq_exit': > /media/anil/kernel/drivers/mfd/tps65910.c:265: undefined reference to > `regmap_del_irq_chip' > drivers/built-in.o: In function `tps65910_irq_init': > /media/anil/kernel/drivers/mfd/tps65910.c:254: undefined reference to > `regmap_add_irq_chip' > drivers/built-in.o: In function `tps65910_i2c_probe': > /media/anil/kernel/drivers/mfd/tps65910.c:509: undefined reference to > `regmap_irq_get_domain' > make: *** [vmlinux] Error 1 > > Signed-off-by: AnilKumar Ch > --- > drivers/mfd/Kconfig |1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index 1c0abd4..01413a2 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -237,6 +237,7 @@ config MFD_TPS65910 > depends on I2C=y && GPIOLIB > select MFD_CORE > select REGMAP_I2C > + select REGMAP_IRQ > select IRQ_DOMAIN > help > if you say yes here you get support for the TPS65910 series of Hi Samuel, If there are no comments on this patch could you please pull? Thanks AnilKumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH RESEND] regulator: tps65910: fix BUG_ON() shown with vrtc regulator
On Wed, Nov 14, 2012 at 11:49:14, Mark Brown wrote: > On Wed, Nov 14, 2012 at 11:24:39AM +0530, AnilKumar Ch wrote: > > Fix BUG_ON() error if tps65910 VRTC regulator is used with out > > rdev->desc->volt_table data. Recent changes in regulator core driver > > which add support for "regulator_list_voltage_table" have BUG_ON() if > > regulator descriptor do not have voltage table information. This patch > > adds the voltage table information to fix the issue. > > This is already applied... got dropped from -next for a day for some > reason but it's there. When resending please do say why. > Hi Mark, Sorry for the noise (My bad missed the version change details). I have checked in regulator/for-next tree and not found, so resend the patch thanks for you time. Thanks AnilKumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/2] Input: matrix-keypad - remove const from pointer to array of gpios
On Sat, Oct 20, 2012 at 04:30:59, Dmitry Torokhov wrote: > On Fri, Oct 19, 2012 at 12:36:12PM +0530, AnilKumar Ch wrote: > > Remove const from pointer to array of gpios in matrix_keypad_platform_data > > struct. This is required if we update row_gpios and col_gpios based on > > device tree data. > > Then don't. Set them up via non-const aliases instead. > Changed. Thanks AnilKumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/2] Input: matrix-keypad - Add device tree support
Hi Rob,
Thanks for the comments.
On Fri, Oct 19, 2012 at 18:27:21, Rob Herring wrote:
> On 10/19/2012 02:06 AM, AnilKumar Ch wrote:
> > Add device tree support to matrix keypad driver and usage details
> > are added to device tree documentation. Driver was tested on AM335x
> > EVM.
> >
> > Signed-off-by: AnilKumar Ch
> > ---
> > .../devicetree/bindings/input/matrix-keypad.txt| 52 ++
> > drivers/input/keyboard/matrix_keypad.c | 104
> > +++-
> > 2 files changed, 155 insertions(+), 1 deletion(-)
> > create mode 100644
> > Documentation/devicetree/bindings/input/matrix-keypad.txt
> >
> > diff --git a/Documentation/devicetree/bindings/input/matrix-keypad.txt
> > b/Documentation/devicetree/bindings/input/matrix-keypad.txt
> > new file mode 100644
> > index 000..50aaa6e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/matrix-keypad.txt
> > @@ -0,0 +1,52 @@
> > +* GPIO driven matrix keypad device tree bindings
> > +
> > +GPIO driven matrix keypad is used to interface a SoC with a matrix keypad.
> > +The matrix keypad supports multiple row and column lines, a key can be
> > +placed at each intersection of a unique row and a unique column. The matrix
> > +keypad can sense a key-press and key-release by means of GPIO lines and
> > +report the event using GPIO interrupts to the cpu.
> > +
> > +Required Properties:
> > +- compatible: Should be "matix-keypad"
>
> How about gpio-matrix-keypad?
More meaningful, changed
>
> > +- keypad,num-row-gpios:Number of row lines connected to the keypad
> > + controller.
> > +- keypad,num-col-gpios:Number of column lines connected to the keypad
> > + controller.
>
> Isn't the number of gpios just the count of gpios listed below? So you
> don't need these props.
Removed
>
> > +- row-gpios: List of gpios used as row lines. The gpio
> > specifier
> > + for this property depends on the gpio controller to
> > + which these row lines are connected.
> > +- col-gpios: List of gpios used as column lines. The gpio
> > specifier
> > + for this property depends on the gpio controller to
> > + which these column lines are connected.
> > +
> > +Optional Properties:
> > +- linux,no-autorepeat: do no enable autorepeat feature.
> > +- linux,wakeup:use any event on keypad as wakeup event.
> > +- debounce-delay-ms: debounce interval in milliseconds
> > +- col-scan-delay-us: delay, measured in microseconds, that is needed
> > + before we can scan keypad after activating column gpio
> > +- clustered-irq: have clustered irq number
> > +- clustered-irq-flags: have clustered irq flags
>
> It's not clear what clustered means here. If I have to go read Linux
> code to understand, you are doing it wrong. Describe the h/w, not Linux
> data structs.
I have added based on pdata of the driver, I am not using these
parameters because AM335x-EVM have different interrupts for all
gpio pins.
clustered-irq: combined irq source for the whole matrix keypad,
like all gpio keys are connected to a gpio expander
>
> > +
> > +Example:
> > + matrix-keypad {
> > + compatible = "matrix-keypad";
> > + keypad,num-row-gpios = <3>;
> > + keypad,num-col-gpios = <2>;
> > + debounce-delay-ms = <5>;
> > + col-scan-delay-us = <2>;
> > +
> > + row-gpios = <&gpio2 25 0
> > +&gpio2 26 0
> > +&gpio2 27 0>;
> > +
> > + col-gpios = <&gpio2 21 0
> > +&gpio2 22 0>;
> > +
> > + linux,keymap = <0x008B
> > + 0x019E
> > + 0x0269
> > + 0x0001006A
> > + 0x0101001C
> > + 0x0201006C>;
> > + };
> > diff --git a/drivers/input/keyboard/matrix_keypad.c
> > b/drivers/input/keyboard/matrix_keypad.c
> > index 18b7237..39e480d 100644
> > --- a/drivers/input/keyboard/matrix_keypad.c
> > +++ b/drivers/input/keyboard/matrix_keypad.c
> > @@ -23,6 +23,9 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > +#include
> >
> > struct matrix_keypad {
> > const struct matrix_keypad_platform_data *pdata;
> > @@ -394,6 +397,91 @@ static void matrix_keypad_free_gpio(struct
> > matrix_keypad *keypad)
> > gpio_free(pdata->col_gpios[i]);
> > }
> >
> > +#ifdef CONFIG_OF
> > +static
> > +struct matrix_keypad_platform_data *matrix_keypad_parse_dt(struct device
> > *dev)
> > +{
> > + struct matrix_keypad_platform_data *pdata;
> > + struct matrix_keymap_data *keymap_data;
> > + struct device_node *np = dev->of_node;
> > + struct property *prop;
> > + int key_count = 0, length, row, col;
> > + uint32_t *keymap;
> > +
> > + pdat
RE: [RFC PATCH v3 13/16] ARM: dts: add AM33XX MMC support
On Thu, Oct 18, 2012 at 18:56:52, Porter, Matt wrote:
> Adds AM33XX MMC support for am335x-bone and am335x-evm.
>
> Signed-off-by: Matt Porter
> ---
> arch/arm/boot/dts/am335x-bone.dts |6 ++
> arch/arm/boot/dts/am335x-evm.dts |6 ++
> arch/arm/boot/dts/am33xx.dtsi | 27 +++
> 3 files changed, 39 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am335x-bone.dts
> b/arch/arm/boot/dts/am335x-bone.dts
> index c634f87..5510979 100644
> --- a/arch/arm/boot/dts/am335x-bone.dts
> +++ b/arch/arm/boot/dts/am335x-bone.dts
> @@ -70,6 +70,8 @@
> };
>
> ldo3_reg: regulator@5 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
I think these min & max limits are regulator limits. Are these fields
required? Add details of these additions. AFAIK fine-tuned (board
specific) min/max limits should be add here(like mpu and core
regulator nodes)
> regulator-always-on;
> };
>
> @@ -78,3 +80,7 @@
> };
> };
> };
> +
> +&mmc1 {
> + vmmc-supply = <&ldo3_reg>;
> +};
> diff --git a/arch/arm/boot/dts/am335x-evm.dts
> b/arch/arm/boot/dts/am335x-evm.dts
> index 185d632..d63fce8 100644
> --- a/arch/arm/boot/dts/am335x-evm.dts
> +++ b/arch/arm/boot/dts/am335x-evm.dts
> @@ -114,7 +114,13 @@
> };
>
> vmmc_reg: regulator@12 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
=same=
> regulator-always-on;
> };
> };
> };
> +
> +&mmc1 {
> + vmmc-supply = <&vmmc_reg>;
> +};
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index ab9c78f..26a6af7 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -234,6 +234,33 @@
> status = "disabled";
> };
>
> + mmc1: mmc@4806 {
> + compatible = "ti,omap3-hsmmc";
> + ti,hwmods = "mmc1";
> + ti,dual-volt;
> + ti,needs-special-reset;
> + dmas = <&edma 24
> + &edma 25>;
> + dma-names = "tx", "rx";
Add status = "disabled" here and "okay" in corresponding
.dts file
> + };
> +
> + mmc2: mmc@481d8000 {
> + compatible = "ti,omap3-hsmmc";
> + ti,hwmods = "mmc2";
> + ti,needs-special-reset;
> + dmas = <&edma 2
> + &edma 3>;
> + dma-names = "tx", "rx";
> + status = "disabled";
> + };
> +
> + mmc3: mmc@4781 {
> + compatible = "ti,omap3-hsmmc";
> + ti,hwmods = "mmc3";
> + ti,needs-special-reset;
What about DMA resources for mmc3?
AnilKumar
> + status = "disabled";
> + };
> +
> wdt2: wdt@44e35000 {
> compatible = "ti,omap3-wdt";
> ti,hwmods = "wd_timer2";
> --
> 1.7.9.5
>
> ___
> devicetree-discuss mailing list
> devicetree-disc...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2] lis3lv02d: Add STMicroelectronics lis331dlh digital accelerometer
Hi Eric,
Thanks for the comments,
On Mon, Sep 24, 2012 at 03:08:19, Éric Piel wrote:
> On 22-08-12 08:30, AnilKumar Ch wrote:
> > This patch adds support for lis331dlh digital accelerometer to the
> > lis3lv02d driver family. Adds ID field for detecting the lis331dlh
> > module, based on this ID field lis3lv02d driver will export the
> > lis331dlh module functionality.
>
> Hello AnilKumar,
>
> Sorry for taking so long to review your patch. Overall, it looks great :-)
>
> There are just a few points that almost code-style/comment that needs to
> be fixed. See below. Could you fix these small issues, and submit a new
> patch for Andrew to pick it in his queue?
As I can see this patch is already in linux-next, I will submit
a new patch by addressing all your comments.
>
> Here is my:
> Reviewed-by: Éric Piel
>
>
> >
> > Signed-off-by: AnilKumar Ch
> > ---
> > Changes from v1:
> > - Removed G range sysfs entry from v1
> > - Modified documentation to specify lis331dlh is supported
> >
> > Documentation/misc-devices/lis3lv02d |3 ++-
> > drivers/misc/lis3lv02d/lis3lv02d.c | 42
> > +-
> > drivers/misc/lis3lv02d/lis3lv02d.h | 44
> > +++-
> > drivers/misc/lis3lv02d/lis3lv02d_i2c.c |7 -
> > 4 files changed, 87 insertions(+), 9 deletions(-)
> >
> > diff --git a/Documentation/misc-devices/lis3lv02d
> > b/Documentation/misc-devices/lis3lv02d
> > index f1a4ec8..af815b9 100644
> > --- a/Documentation/misc-devices/lis3lv02d
> > +++ b/Documentation/misc-devices/lis3lv02d
> > @@ -4,7 +4,8 @@ Kernel driver lis3lv02d
> > Supported chips:
> >
> > * STMicroelectronics LIS3LV02DL, LIS3LV02DQ (12 bits precision)
> > - * STMicroelectronics LIS302DL, LIS3L02DQ, LIS331DL (8 bits)
> > + * STMicroelectronics LIS302DL, LIS3L02DQ, LIS331DL (8 bits) and
> > +LIS331DLH (16 bits)
> >
> > Authors:
> > Yan Burman
> > diff --git a/drivers/misc/lis3lv02d/lis3lv02d.c
> > b/drivers/misc/lis3lv02d/lis3lv02d.c
> > index 29d12a7..c0a9199 100644
> > --- a/drivers/misc/lis3lv02d/lis3lv02d.c
> > +++ b/drivers/misc/lis3lv02d/lis3lv02d.c
> > @@ -80,6 +80,14 @@
> > #define LIS3_SENSITIVITY_12B ((LIS3_ACCURACY * 1000) / 1024)
> > #define LIS3_SENSITIVITY_8B (18 * LIS3_ACCURACY)
> >
> > +/*
> > + * LIS3331DLH spec says 1LSBs corresponds 4G/1024 -> 1LSB is 1000/1024 mG.
> > + * Sensitivity values for +/-2G, outdata in 12 bits for +/-2G scale. so 4
> > + * bits adjustment is required
> > + */
> > +#define LIS3DLH_SENSITIVITY_2G ((LIS3_ACCURACY * 1000) / 1024)
> > +#define SHIFT_ADJ_2G 4
> > +
> You said later:
> >
> > Typo mistake this should be 4G/4096
> Could you fix the comment. Even better, change LIS3331DLH to LIS331DLH
>
> Also, if I understand correctly, there is currently no support for
> changing the sensitivity. It stays at 2G all the time, right? In such
> case, please add a sentence in this comment that the driver does only
> support the 2G sensitivity for now.
I will do this
>
>
> > #define LIS3_DEFAULT_FUZZ_12B 3
> > #define LIS3_DEFAULT_FLAT_12B 3
> > #define LIS3_DEFAULT_FUZZ_8B 1
> > @@ -133,6 +141,19 @@ static s16 lis3lv02d_read_12(struct lis3lv02d *lis3,
> > int reg)
> > return (s16)((hi << 8) | lo);
> > }
> >
> > +/* 12bits for 2G range, 13 bits for 4G range and 14 bits for 8G range */
> > +static s16 lis3lv02d_read_16(struct lis3lv02d *lis3, int reg)
> > +{
> > + u8 lo, hi;
> > + int v;
> > +
> > + lis3->read(lis3, reg - 1, &lo);
> > + lis3->read(lis3, reg, &hi);
> > + v = (int) ((hi << 8) | lo);
> > +
> > + return (s16) v >> lis3->shift_adj;
> > +}
> As the method reads 12, 13, or 14 bits, it's a bit tricky to call it
> "*_read_16". I'd suggest maybe "lis3lv02d_read_12_14",
> "lis3lv02d_read_adj_16", or even "lis331dlh_read_data". Pick the one you
> prefer :-)
Comment is available to convey the number of bits so I am changing it to
"lis331dlh_read_data".
>
>
> > /**
> >* lis3lv02d_get_axis - For the given axis, give the value converted
> >* @axis: 1,2,3 - can also be negative
> > @@ -193,6 +214,7 @@ static void lis3lv02d_get_xyz(struct lis3lv02d *lis3,
> > int *x, int *y, int *z)
> > static int lis3_12_rates[4] = {40, 160, 640, 2560};
> > static int lis3_8_rates[2] = {100, 400};
> > static int lis3_3dc_rates[16] = {0, 1, 10, 25, 50, 100, 200, 400, 1600,
> > 5000};
> > +static int lis3_3dlh_rates[4] = {50, 100, 400, 1000};
> >
> > /* ODR is Output Data Rate */
> > static int lis3lv02d_get_odr(struct lis3lv02d *lis3)
> > @@ -265,7 +287,7 @@ static int lis3lv02d_selftest(struct lis3lv02d *lis3,
> > s16 results[3])
> > (LIS3_IRQ1_DATA_READY | LIS3_IRQ2_DATA_READY));
> > }
> >
> > - if (lis3->whoami == WAI_3DC) {
> > + if ((lis3->whoami == WAI_3DC) || (lis3->whoami == WAI_3DLH)) {
> > ctl
RE: [PATCH RFT] regulator: tps65217: Convert to regulator_[is_enabled|get_voltage_sel]_regmap
On Fri, Sep 07, 2012 at 20:00:59, Mark Brown wrote: > On Fri, Sep 07, 2012 at 02:26:53PM +0000, AnilKumar, Chimata wrote: > > On Fri, Sep 07, 2012 at 19:51:51, Mark Brown wrote: > > > > You didn't send a patch. > > > Its there, above to my comment > > https://lkml.org/lkml/2012/6/18/308 > > Right, but my reply was saying we should do something different so I was > expecting an update which implemented one of the suggestions. I will send the formal patch. Thanks AnilKumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH RFT] regulator: tps65217: Convert to regulator_[is_enabled|get_voltage_sel]_regmap
On Fri, Sep 07, 2012 at 19:51:51, Mark Brown wrote: > On Fri, Sep 07, 2012 at 02:19:59PM +0000, AnilKumar, Chimata wrote: > > > Currently this is not properly taken care, is there are any specific > > reasons for this? > > You didn't send a patch. > Its there, above to my comment https://lkml.org/lkml/2012/6/18/308 Thanks AnilKumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH RFT] regulator: tps65217: Convert to regulator_[is_enabled|get_voltage_sel]_regmap
On Mon, Jun 18, 2012 at 18:15:14, Mark Brown wrote: > On Mon, Jun 18, 2012 at 12:39:38PM +0000, AnilKumar, Chimata wrote: > > > + if (config->regmap) > > + rdev->regmap = config->regmap; > > + else > > + rdev->regmap = dev_get_regmap(dev->parent, NULL); > > No, this would be broken. We're specifically using the device we got > passed in. In this case the fact that the regmap is on the MFD means > that the driver does need to explicitly set the regmap. Or we should > have this be a multi-stage series of checks: > > if (config->regmap) > rdev->regmap = config->regmap; > else if (dev_get_regmap(dev, NULL)) > rdev->regmap = dev_get_regmap(dev, NULL); > else if (dev->parent) > rdev->regmap = dev_get_regmap(dev->parent, NULL); > > which should cover the MFD case if there's no regmap on the child > without having to go through all the drivers doing it by hand. > Mark, Currently this is not properly taken care, is there are any specific reasons for this? Thanks AnilKumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2] lis3lv02d: Add STMicroelectronics lis331dlh digital accelerometer
Hi Eric, On Wed, Aug 22, 2012 at 13:18:38, Arnd Bergmann wrote: > On Wednesday 22 August 2012, AnilKumar Ch wrote: > > This patch adds support for lis331dlh digital accelerometer to the > > lis3lv02d driver family. Adds ID field for detecting the lis331dlh > > module, based on this ID field lis3lv02d driver will export the > > lis331dlh module functionality. > > > > Signed-off-by: AnilKumar Ch > > Acked-by: Arnd Bergmann > If there are no further comments could you please push this patch? Thanks AnilKumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2] lis3lv02d: Add STMicroelectronics lis331dlh digital accelerometer
Chinmay, On Thu, Aug 23, 2012 at 15:53:10, Chinmay V S wrote: > > Note from datasheet, "1LSb=4g/4096 at 12bit representation, > > ±2g Full-scale" > > Precisely my point. All the datasheet says is : > 1. It is +/-2G mode --> so Numerator is 4G. > 2. We are using 12bits --> so Denominator is 2^12 = 4096. > > There is no clear reason/justification as to why 12bits was chosen in > the first place. At this point unless someone from the > design/original-driver team actually confirms why the 12bit > representation was chosen, it is all conjecture on our part. > > If you have the actual LIS331DLH hardware, can you verify if the lower > 4bits do actually contain any data (or are they always zero). This > will help us decide whether to use them(16bit mode) or discard > them(12bit mode)?... > This is the outdata of accelerometer root@am335xevm:~# cat /sys/devices/platform/lis3lv02d/position [ 16.323852] lis3lv02d: hi 0x1low 0x50 val 0x15 [ 16.329742] lis3lv02d: hi 0x0low 0x0val 0x0 [ 16.335052] lis3lv02d: hi 0x3e low 0x50 val 0x3e5 (20,0,973) root@am335xevm:~# cat /sys/devices/platform/lis3lv02d/position [ 25.777343] lis3lv02d: hi 0x2low 0xa0 val 0x2a [ 25.783203] lis3lv02d: hi 0xc1 low 0xf0 val 0xfc1f [ 25.790130] lis3lv02d: hi 0xfd low 0x50 val 0xffd5 (41,-969,-41) root@am335xevm:~# cat /sys/devices/platform/lis3lv02d/position [ 47.607330] lis3lv02d: hi 0xc0 low 0x60 val 0xfc06 [ 47.613464] lis3lv02d: hi 0xfd low 0x90 val 0xffd9 [ 47.619934] lis3lv02d: hi 0x2low 0x40 val 0x24 (-994,-38,35) Lower nibble always "0" Regards AnilKumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2] lis3lv02d: Add STMicroelectronics lis331dlh digital accelerometer
On Wed, Aug 22, 2012 at 22:24:10, Chinmay V S wrote: > > Look at this application note which talks about the outdata values > > for 2G range (page 12/31) > > http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00215823.pdf > > Had been through the application note earlier. The table5 (on page 12) > that you refer to, does NOT contradict either 12/16bit, as in all the > examples the lower 4 bits are zero. So i don't see how one can assume > from these examples that for +/-2G they one should consider 12/16bits. > A nice side-effect of using 12|13|14bits for +/-2|4|8G is that the > values returned by the driver are in mG in all the 3 modes. > > > Corresponding to the 4G and 8G I got the details form older > > patches (SHIFT_ADJ_4G and SHIFT_ADJ_8G). > > http://driverdev.linuxdriverproject.org/pipermail/devel/2010-November/009685.html > > > > We can easily interpret number of bits for 4G and 8G from 2G > > information. > > Going through the code of this driver i can see what you are talking > about. Depending on the full-scale-range the device is being > configured for, the number of bits used to represent acceleration in > the driver is changed. > > Again judging from the code, the driver is always returning > acceleration at a constant accuracy i.e. 1mG in all the 3 modes > (+/-2|4|8G)i.e. > +/-2G is mode means value can be anywhere from +/-2048mG, > (requiring 12bits.) > +/-4G in the range of +/-4096mG, requiring 13bits. > +/-8G i.e. +/-8192mG, requiring 14bits. > > Was this done... > > a. ...because LIS331DLH's theoretical MAX accuracy is ~1mG > If yes, then using 12bits is fine. > Note from datasheet, "1LSb=4g/4096 at 12bit representation, ±2g Full-scale" >From this I understood that ±2G full scale value is 12 bits. That is one more reason to take 12bit value. Regards AnilKumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2] lis3lv02d: Add STMicroelectronics lis331dlh digital accelerometer
On Wed, Aug 22, 2012 at 16:09:22, Chinmay V S wrote: > Hmmm. Interesting. As i understand LIS331DLH provides 16bit data > irrespective of the full-scale/sensitivity configuration. Hence we > could effectively map +/-2G to +/-32768(signed 16bit 2's complement). > According to the current-patch right-shifting the register values by > 4(i.e. reducing 16bit --> 12bit) will mean that we lose accuracy by > ~1mG. > > Clearly this will NOT affect use-case like display-orientation in > smart-phones, but surely medical and industrial applications WILL > benefit from the additional accuracy by utilising the entire 16-bit > resolution provided by LIS331DLH hardware. > > I went through the LIS331DLH datasheet/application-note from > http://www.st.com/internet/analog/product/218132.jsp and i'm a bit > confused from your statement about +/-2G being 12bit data. Nowhere is > it mentioned that LIS331DLH provides +/-2G|+/-4G|+/-8G as 12|13|14 bit > data respectively. Then again i might be wrong... > Look at this application note which talks about the outdata values for 2G range (page 12/31) http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00215823.pdf Corresponding to the 4G and 8G I got the details form older patches (SHIFT_ADJ_4G and SHIFT_ADJ_8G). http://driverdev.linuxdriverproject.org/pipermail/devel/2010-November/009685.html We can easily interpret number of bits for 4G and 8G from 2G information. Thanks AnilKumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2] lis3lv02d: Add STMicroelectronics lis331dlh digital accelerometer
Hi Chinmay,
Thanks for the comments
On Wed, Aug 22, 2012 at 14:14:55, Chinmay V S wrote:
> Hi All,
>
> A few nitpicks.
>
> > + * LIS3331DLH spec says 1LSBs corresponds 4G/1024 -> 1LSB is 1000/1024 mG.
> > + * Sensitivity values for +/-2G, outdata in 12 bits for +/-2G scale. so 4
> > + * bits adjustment is required
> Shouldn't it be "1LSB is 4000/1024 mG" ?
Typo mistake this should be 4G/4096
> Also "outdata in 12bits" (typo. in->is?)
>
If we look at the lis331dlh datasheet 12 bits outdata for +/- 2G resolution
range and 13 bits for +/- 4G range and 14 bits for +/- 8G range. So output
data is only 12 bits.
> On a more technical note, now that LIS3331DLH has 16bit resolution,
> why don't we simply return the entire 16-bit value in
> lis3lv02d_read_16(). The fact that lis3lv02d_read_16() has 16-bit
> resolution can be indicated by
Depending on the range 2 or 4 or 8 we have to pass the outdata that is
handled by using the shift_adj member to shift the outdata to corresponding
bits 12/13/14.
>
> @@ -954,6 +984,16 @@ int lis3lv02d_init_device(struct lis3lv02d *lis3)
> lis3->odr_mask = CTRL1_ODR0|CTRL1_ODR1|CTRL1_ODR2|CTRL1_ODR3;
> lis3->scale = LIS3_SENSITIVITY_8B;
> break;
> + case WAI_3DLH:
> + pr_info("16 bits 3DLH sensor found\n");
> + lis3->read_data = lis3lv02d_read_16;
> + lis3->mdps_max_val = 32768; /* 16 bits for +/-2G */
This driver supports only +/-2G range of values so it is limited to 2048.
With this we do not have the runtime change of G range so by default 2G
is added.
Regards
AnilKumar
RE: linux-next: Tree for July 17 (mfd/tps65217.c)
Hi Samuel, On Tue, Aug 21, 2012 at 23:21:37, Randy Dunlap wrote: > On 08/05/2012 11:38 PM, AnilKumar, Chimata wrote: > > > On Fri, Aug 03, 2012 at 22:58:01, Randy Dunlap wrote: > >> On 07/17/2012 02:48 PM, Randy Dunlap wrote: > >> > >>> On 07/16/2012 10:41 PM, Stephen Rothwell wrote: > >>> > >>>> Hi all, > >>>> > >>>> Changes since 20120716: > >>>> > >>> > >>> > >>> on i386: > >>> > >>> drivers/built-in.o: In function `tps65217_probe': > >>> tps65217.c:(.devinit.text+0x13e37): undefined reference to > >>> `of_regulator_match' > >>> > >>> > >>> Full randconfig file is attached. > >>> CONFIG_REGULATOR is not enabled. > >>> > >> > >> > >> This build error is still present in linux-next of 20120803. > >> > > > > This will be fixed with this patch > > https://patchwork.kernel.org/patch/1220151/ > > > > Today, I will submit v2 for this > > > This build still fails in linux-next 20120821. Could you please push this patch ASAP? http://www.spinics.net/lists/linux-omap/msg75336.html Thanks AnilKumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v3 1/2] lis3: add generic DT matching code
Hi Mack,
No attachments please.
On Wed, Aug 08, 2012 at 00:19:01, Daniel Mack wrote:
> Hi,
>
> thanks for your review.
>
> On 06.08.2012 12:45, AnilKumar, Chimata wrote:
> > On Sun, Aug 05, 2012 at 21:48:42, Daniel Mack wrote:
> >> On 30.07.2012 09:36, Daniel Mack wrote:
> >>> This patch adds logic to parse lis3 properties from a device tree node
> >>> and store them in a freshly allocated lis3lv02d_platform_data.
> >>>
> >>> Note that the actual match tables are left out here. This part should
> >>> happen in the drivers that bind to the individual busses (SPI/I2C/PCI).
> >>>
> >>> Also adds some DT bindinds documentation.
> >>>
> >>> Signed-off-by: Daniel Mack
> >>> ---
> >>> Changes from v2:
> >>> - kzalloc braino
> >>>
> >>> Changes from v1:
> >>> - some typos in properties fixed
> >>>
> >>>
> >>> Documentation/devicetree/bindings/misc/lis302.txt | 74
> >>> drivers/misc/lis3lv02d/lis3lv02d.c| 137
> >>> ++
> >>> drivers/misc/lis3lv02d/lis3lv02d.h| 4 +
> >>> 3 files changed, 215 insertions(+)
> >>> create mode 100644 Documentation/devicetree/bindings/misc/lis302.txt
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/misc/lis302.txt
> >>> b/Documentation/devicetree/bindings/misc/lis302.txt
> >>> new file mode 100644
> >>> index 000..66230fd
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/misc/lis302.txt
> >>> @@ -0,0 +1,74 @@
> >>> +LIS302 accelerometer devicetree bindings
> >>> +
> >>> +This device is matched via its bus drivers, and has a number of
> >>> properties
> >>> +that apply in on the generic device (independent from the bus).
> >>> +
> >>> +
> >>> +Required properties for the SPI bindings:
> >>> + - compatible: should be set to "st,lis3lv02d_spi"
> >>> + - reg: the chipselect index
> >>> + - spi-max-frequency:maximal bus speed, should be set to 100
> >>> unless
> >>> + constrained by external circuitry
> >>> + - interrupts: the interrupt generated by the device
> >>> +
> >>> +
> >>> +Optional properties for all bus drivers:
> >>> +
> >>> + - st,click-single-{x,y,z}: if present, tells the device to issue an
> >>> + interrupt on single click events on the
> >>> + x/y/z axis.
> >>> + - st,click-double-{x,y,z}: if present, tells the device to issue an
> >>> + interrupt on double click events on the
> >>> + x/y/z axis.
> >>> + - st,click-thresh-{x,y,z}: set the x/y/z axis threshold
> >>> + - st,click-click-time-limit:click time limit, from 0 to 127.5msec
> >>> + with step of 0.5 msec
> >>> + - st,click-latency: click latency, from 0 to 255 msec with
> >>> + step of 1 msec.
> >>> + - st,click-window: click window, from 0 to 255 msec with
> >>> + step of 1 msec.
> >>> + - st,irq{1,2}-disable: disable IRQ 1/2
> >>> + - st,irq{1,2}-ff-wu-1: raise IRQ 1/2 on FF_WU_1 condition
> >>> + - st,irq{1,2}-ff-wu-2: raise IRQ 1/2 on FF_WU_2 condition
> >>> + - st,irq{1,2}-data-ready: raise IRQ 1/2 on data ready contition
> >>> + - st,irq{1,2}-click:raise IRQ 1/2 on click condition
> >>> + - st,irq-open-drain:consider IRQ lines open-drain
> >>> + - st,irq-active-low:make IRQ lines active low
> >>> + - st,wu-duration-1: duration register for Free-Fall/Wake-Up
> >>> + interrupt 1
> >>> + - st,wu-duration-2: duration register for Free-Fall/Wake-Up
> >>> + interrupt 2
> >>> + - st,wakeup-{x,y,z}-{lo,hi}:set wakeup condition on x/y/z axis for
> >>> + upper/lower limit
> >>> + - st,highpass-cutoff-hz=: 1, 2, 4 or 8 for 1Hz, 2Hz, 4Hz or 8Hz of
> >>> + highpass cut-off frequency
> &g
RE: [PATCH v3 1/2] lis3: add generic DT matching code
On Sun, Aug 05, 2012 at 21:48:42, Daniel Mack wrote:
> Ping, anyone?
>
> On 30.07.2012 09:36, Daniel Mack wrote:
> > This patch adds logic to parse lis3 properties from a device tree node
> > and store them in a freshly allocated lis3lv02d_platform_data.
> >
> > Note that the actual match tables are left out here. This part should
> > happen in the drivers that bind to the individual busses (SPI/I2C/PCI).
> >
> > Also adds some DT bindinds documentation.
> >
> > Signed-off-by: Daniel Mack
> > ---
> > Changes from v2:
> > - kzalloc braino
> >
> > Changes from v1:
> > - some typos in properties fixed
> >
> >
> > Documentation/devicetree/bindings/misc/lis302.txt | 74
> > drivers/misc/lis3lv02d/lis3lv02d.c| 137
> > ++
> > drivers/misc/lis3lv02d/lis3lv02d.h| 4 +
> > 3 files changed, 215 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/misc/lis302.txt
> >
> > diff --git a/Documentation/devicetree/bindings/misc/lis302.txt
> > b/Documentation/devicetree/bindings/misc/lis302.txt
> > new file mode 100644
> > index 000..66230fd
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/misc/lis302.txt
> > @@ -0,0 +1,74 @@
> > +LIS302 accelerometer devicetree bindings
> > +
> > +This device is matched via its bus drivers, and has a number of properties
> > +that apply in on the generic device (independent from the bus).
> > +
> > +
> > +Required properties for the SPI bindings:
> > + - compatible: should be set to "st,lis3lv02d_spi"
> > + - reg:the chipselect index
> > + - spi-max-frequency: maximal bus speed, should be set to 100
> > unless
> > + constrained by external circuitry
> > + - interrupts: the interrupt generated by the device
> > +
> > +
> > +Optional properties for all bus drivers:
> > +
> > + - st,click-single-{x,y,z}:if present, tells the device to issue an
> > + interrupt on single click events on the
> > + x/y/z axis.
> > + - st,click-double-{x,y,z}:if present, tells the device to issue an
> > + interrupt on double click events on the
> > + x/y/z axis.
> > + - st,click-thresh-{x,y,z}:set the x/y/z axis threshold
> > + - st,click-click-time-limit: click time limit, from 0 to 127.5msec
> > + with step of 0.5 msec
> > + - st,click-latency: click latency, from 0 to 255 msec with
> > + step of 1 msec.
> > + - st,click-window:click window, from 0 to 255 msec with
> > + step of 1 msec.
> > + - st,irq{1,2}-disable:disable IRQ 1/2
> > + - st,irq{1,2}-ff-wu-1:raise IRQ 1/2 on FF_WU_1 condition
> > + - st,irq{1,2}-ff-wu-2:raise IRQ 1/2 on FF_WU_2 condition
> > + - st,irq{1,2}-data-ready: raise IRQ 1/2 on data ready contition
> > + - st,irq{1,2}-click: raise IRQ 1/2 on click condition
> > + - st,irq-open-drain: consider IRQ lines open-drain
> > + - st,irq-active-low: make IRQ lines active low
> > + - st,wu-duration-1: duration register for Free-Fall/Wake-Up
> > + interrupt 1
> > + - st,wu-duration-2: duration register for Free-Fall/Wake-Up
> > + interrupt 2
> > + - st,wakeup-{x,y,z}-{lo,hi}: set wakeup condition on x/y/z axis for
> > + upper/lower limit
> > + - st,highpass-cutoff-hz=: 1, 2, 4 or 8 for 1Hz, 2Hz, 4Hz or 8Hz of
> > + highpass cut-off frequency
> > + - st,hipass{1,2}-disable: disable highpass 1/2.
> > + - st,default-rate=: set the default rate
> > + - st,axis-{x,y,z}=: set the axis to map to the three
> > coordinates
Some more parameters missing, what about st_min_limits and st_max_limits
required for selftest.
> > +
> > +
> > +Example for a SPI device node:
> > +
> > + lis302@0 {
> > + compatible = "st,lis302dl-spi";
> > + reg = <0>;
> > + spi-max-frequency = <100>;
> > + interrupt-parent = <&gpio>;
> > + interrupts = <104 0>;
> > +
> > + st,click-single-x;
> > + st,click-single-y;
> > + st,click-single-z;
> > + st,click-thresh-x = <10>;
> > + st,click-thresh-y = <10>;
> > + st,click-thresh-z = <10>;
> > + st,irq1-click;
> > + st,irq2-click;
> > + st,wakeup-x-lo;
> > + st,wakeup-x-hi;
> > + st,wakeup-y-lo;
> > + st,wakeup-y-hi;
> > + st,wakeup-z-lo;
> > + st,wakeup-z-hi;
> > + };
Why can't we add these flags in driver itself like below?
Is these parameters varies from SoC to SoC or accelerometer
- to - accelerometer?
#ifdef CONFIG_OF
static stru
RE: linux-next: Tree for July 17 (mfd/tps65217.c)
On Fri, Aug 03, 2012 at 22:58:01, Randy Dunlap wrote: > On 07/17/2012 02:48 PM, Randy Dunlap wrote: > > > On 07/16/2012 10:41 PM, Stephen Rothwell wrote: > > > >> Hi all, > >> > >> Changes since 20120716: > >> > > > > > > on i386: > > > > drivers/built-in.o: In function `tps65217_probe': > > tps65217.c:(.devinit.text+0x13e37): undefined reference to > > `of_regulator_match' > > > > > > Full randconfig file is attached. > > CONFIG_REGULATOR is not enabled. > > > > > This build error is still present in linux-next of 20120803. > This will be fixed with this patch https://patchwork.kernel.org/patch/1220151/ Today, I will submit v2 for this Regards AnilKumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] lis3lv02d: Add STMicroelectronics lis33ldlh digital
Hi Arnd, On Thu, Jan 19, 2012 at 22:40:45, Arnd Bergmann wrote: > On Thursday 19 January 2012, AnilKumar, Chimata wrote: > > Android userspace running on TI AM335x EVM is using the interface > > provided by lis3lv02d. They were asking some more interfaces from > > lis3lvo2d driver. > > > > There are multiple ways we can interface accelerometer to Android layers, > > which is implemented on hardware abstraction layer (HAL) in Andriod. > > > > 1) Interrupt mode > > 2) Polling mode > >2a) Kernel polling > >2b) Timer polling > > > > Based on the interfaces provided by the lis3lv02d as well as > > lis331dlh (H/W not supporting the interrupts) they were implementing > > the kernel polling mechanism. > > > > So implementation on HAL is like this if accelerometer interface is > > opened then kernel will start polling this driver periodically and > > pass events to input subsystem. (It's a little bit over head) > > > > Generally the device should be open but kernel should only poll > > when an app that uses accelerometer is started. > > > > The biggest requirement for them (Andriod people) is to allow user to > > enable / disable accelerometer from user space and to configure > > the accelerometer polling frequency. > > > > Today there is no option in lis3lvo2d driver to provide this kind > > of functionalities > > Hi AnilKumar, > > This all sounds like the interface is not completely thought through. > > I did not realize that the driver actually uses the input subsystem > in addition to its own interfaces. This is definitely good, and it > means that we can move the files from drivers/misc to drivers/input/misc > or drivers/input/accelerometer, making it Dmitry's problem instead of > mine ;-) > > Having custom user interfaces inside an input driver however is very > bad. I'm sure that other accelerometers will have the same requirements > regarding polling frequency and enable/disable in android as well as > anytwhere else and it should absolutely not be handled by a user space > HAL but instead inside of the kernel, using a common method for all > available drivers. > > Based on that, I also doubt we should apply your patch to add the > "range" attribute (adding support for lis33ldlh is fine though). > > Instead I would ask you to first fix what's there by moving the > user space interfaces into the input core from the driver > and documenting them. > > I don't know what the preferred way for doing things is there > (joystick ioctl, sysfs attribute, ...) but Dmitry should > be able to provide advice there. Then add interfaces for the > additional stuff you need (range, disable, ...) in the same > place and implement them as callbacks in the driver itself. I will remove the range attribute and I will submit v2. The rest of the patch deals with adding support for lis33ldlh and should be fairly non-controversial. We can revisit the range attribute addition at a later time. Regards AnilKumar
RE: [PATCH] regulator: tps65217: fix build error if REGULATOR is not enabled
Hi Mark, On Wed, Jul 18, 2012 at 15:30:13, Mark Brown wrote: > On Wed, Jul 18, 2012 at 09:55:57AM +0000, AnilKumar, Chimata wrote: > > > Regulators platform data is added to platform device in MFD driver, which we > > need for regulator driver, of_regulator_match() is used to check the > > regulator > > consumers if we pass DT data. If we do not enable CONFIG_REGULATOR then > > of_regulator_match() is not exported, so we see this error. > > Why are you doing that in the MFD driver? > I got your point, I referred tps6586x driver while developing the initial driver. Based on tps6586x MFD driver I added REGULATOR flag. I think tps6586x MFD driver need to be cleaned up. I will submit a patch to make tps65217 MFD driver independent of REGULATOR framework. Thanks AnilKumar-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] regulator: tps65217: fix build error if REGULATOR is not enabled
Mark, On Wed, Jul 18, 2012 at 15:14:49, Mark Brown wrote: > On Wed, Jul 18, 2012 at 12:11:03PM +0530, AnilKumar Ch wrote: > > Fixes below build error if CONFIG_REGULATOR is not enabled. > > > > drivers/built-in.o: In function `tps65217_probe': > > tps65217.c:(.devinit.text+0x13e37): undefined reference to > > `of_regulator_match' > > This isn't a patch to the regulator driver, this is a patch to the MFD. > Normally this would be fixed by making the MFD driver not depend on the > regulator API - why is the MFD driver using the regulator API? > Regulators platform data is added to platform device in MFD driver, which we need for regulator driver, of_regulator_match() is used to check the regulator consumers if we pass DT data. If we do not enable CONFIG_REGULATOR then of_regulator_match() is not exported, so we see this error. Regards AnilKumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 1/3] regulator: tps65217: Add device tree support
+Tony Tony, On Fri, Jul 13, 2012 at 15:24:54, Mark Brown wrote: > On Fri, Jul 13, 2012 at 05:43:30AM +0000, AnilKumar, Chimata wrote: > > > Thanks much, are you going to push reset of the patches in this series? > > No, there's no dependency so I'd expect them to be applied by the > architecture maintainers. > Could you please push these [2/3 and 3/3] patches to linux-omap "devel-dt tree"? http://marc.info/?l=linux-omap&m=134191889501150&w=2 http://marc.info/?l=linux-omap&m=134191891701159&w=2 After these patches, "PMIC I2C slave address addition for AM335x EVM/Bone will be submitted, which actually passes DT data to tps65910/217 drivers" Regards AnilKumar-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 1/3] regulator: tps65217: Add device tree support
Hi Mark, On Thu, Jul 12, 2012 at 22:58:37, Mark Brown wrote: > On Tue, Jul 10, 2012 at 04:39:42PM +0530, AnilKumar Ch wrote: > > This commit adds device tree support for tps65217 pmic. And usage > > details are added to device tree documentation. Driver is tested > > by using kernel module with regulator set and get APIs. > > Applied, thanks. Thanks much, are you going to push reset of the patches in this series? Thanks AnilKumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
