Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1641113 > unrolled thread

Re: [PATCH v2 3/4] iio: accel: adxl345: Setup DATA_READY trigger

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2 3/4] iio: accel: adxl345: Setup DATA_READY trigger Jonathan Cameron <jic23@kernel.org> - 2017-05-14 17:20 +0200
    Re: [PATCH v2 3/4] iio: accel: adxl345: Setup DATA_READY trigger Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-05-14 18:10 +0200

#1641113 — Re: [PATCH v2 3/4] iio: accel: adxl345: Setup DATA_READY trigger

On 10/05/17 14:24, Eva Rachel Retuya wrote:
> On Wed, May 03, 2017 at 12:05:00AM +0300, Andy Shevchenko wrote:
>> On Tue, May 2, 2017 at 3:15 PM, Eva Rachel Retuya <eraretuya@gmail.com> wrote:
>>> On Mon, May 01, 2017 at 02:31:00PM +0300, Andy Shevchenko wrote:
>>> [...]
>>>>> -int adxl345_core_probe(struct device *dev, struct regmap *regmap,
>>>>> +int adxl345_core_probe(struct device *dev, struct regmap *regmap, int irq,
>>>>>                         const char *name);
>>>>
>>>> I think I commented this once. Instead of increasing parameters,
>>>> please introduce a new struct (as separate preparatory patch) which
>>>> will hold current parameters. Let's call it
>>>> strut adxl345_chip {
>>>>   struct device *dev;
>>>>   struct regmap *regmap;
>>>>   const char *name;
>>>> };
>>>>
>>>> I insisnt in this chage.
>>>
>>> I'm not sure if what you want is more simpler, is it something like what
>>> this driver does?
>>
>> Nope. The driver you were referring to does the same you did.
>>
>> I'm proposing the above struct to be introduced along with changing
>> prototype like:
>>
>>   -int adxl345_core_probe(struct device *dev, struct regmap *regmap,
>> const char *name);
>>   +int adxl345_core_probe(struct adxl345_chip *chip);
>>
>> In next patch adding interrupt would not touch prototypes at all!
>>
> 
> OK, got it. Thanks for clarifying.
> 
>>>
>>> http://lxr.free-electrons.com/source/drivers/iio/gyro/mpu3050.h#L41
>>> http://lxr.free-electrons.com/source/drivers/iio/gyro/mpu3050-i2c.c#L34
>>
>>>>> +#include <linux/of_irq.h>
>>>>
>>>> Can we get rid of gnostic resource providers?
>>>>
>>>
>>> I'm uninformed and still learning. Please let me know how to approach
>>> this in some other way.
>>
>> I suppose something like platform_get_irq(); to use.
>> But it would be nice to you to investigate more.
> 
> I had a look and it seems I have to convert to platform_driver in order
> to make use of that function. Is this correct?
I believe Andy was suggesting a function 'similar to' that one rather
than actually using platform_get_irq.

It's not an area I know all that much about either, but there
are moves to try and move the boiler plat needed to get the same
parameters from devicetree and acpi into core library code so
that a single function can be called to get the parameter in
either case.

Jonathan
> 
> Eva
> 
>>
>> -- 
>> With Best Regards,
>> Andy Shevchenko
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[toc] | [next] | [standalone]

#1641143

On Sun, May 14, 2017 at 04:15:37PM +0100, Jonathan Cameron wrote:
> On 10/05/17 14:24, Eva Rachel Retuya wrote:
> >On Wed, May 03, 2017 at 12:05:00AM +0300, Andy Shevchenko wrote:
> >>On Tue, May 2, 2017 at 3:15 PM, Eva Rachel Retuya <eraretuya@gmail.com> wrote:
> >>>On Mon, May 01, 2017 at 02:31:00PM +0300, Andy Shevchenko wrote:
> >>>[...]
> >>>>>-int adxl345_core_probe(struct device *dev, struct regmap *regmap,
> >>>>>+int adxl345_core_probe(struct device *dev, struct regmap *regmap, int irq,
> >>>>>                        const char *name);
> >>>>
> >>>>I think I commented this once. Instead of increasing parameters,
> >>>>please introduce a new struct (as separate preparatory patch) which
> >>>>will hold current parameters. Let's call it
> >>>>strut adxl345_chip {
> >>>>  struct device *dev;
> >>>>  struct regmap *regmap;
> >>>>  const char *name;
> >>>>};
> >>>>
> >>>>I insisnt in this chage.
> >>>
> >>>I'm not sure if what you want is more simpler, is it something like what
> >>>this driver does?
> >>
> >>Nope. The driver you were referring to does the same you did.
> >>
> >>I'm proposing the above struct to be introduced along with changing
> >>prototype like:
> >>
> >>  -int adxl345_core_probe(struct device *dev, struct regmap *regmap,
> >>const char *name);
> >>  +int adxl345_core_probe(struct adxl345_chip *chip);
> >>
> >>In next patch adding interrupt would not touch prototypes at all!
> >>
> >
> >OK, got it. Thanks for clarifying.
> >
> >>>
> >>>http://lxr.free-electrons.com/source/drivers/iio/gyro/mpu3050.h#L41
> >>>http://lxr.free-electrons.com/source/drivers/iio/gyro/mpu3050-i2c.c#L34
> >>
> >>>>>+#include <linux/of_irq.h>
> >>>>
> >>>>Can we get rid of gnostic resource providers?
> >>>>
> >>>
> >>>I'm uninformed and still learning. Please let me know how to approach
> >>>this in some other way.
> >>
> >>I suppose something like platform_get_irq(); to use.
> >>But it would be nice to you to investigate more.
> >
> >I had a look and it seems I have to convert to platform_driver in order
> >to make use of that function. Is this correct?
> I believe Andy was suggesting a function 'similar to' that one rather
> than actually using platform_get_irq.
> 
> It's not an area I know all that much about either, but there
> are moves to try and move the boiler plat needed to get the same
> parameters from devicetree and acpi into core library code so
> that a single function can be called to get the parameter in
> either case.

Well, we of course could look into moving bulk of platform_get_irq()
into generic device_get_irq(), but I think the main problem is that ACPI
(as far as I know) does not have notion of interrupt names...

Thanks.

-- 
Dmitry

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web