[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHNg1SqMRgmtcfdkRmP3abSPLcphQL7rWxO8v5JUOJS0MfAAvQ@mail.gmail.com>
Date: Mon, 11 Jul 2016 14:40:58 +0530
From: Pratik Prajapati <pratik.prajapati12@...il.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: linux-iio@...r.kernel.org, linux-hwmon@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: How to set Current register in IIO driver from sysfs
Hi Jonathan,
Thanks for the answers.
One more question:
What are volatile registers?
I couldn't understood the difference between volatile and writable
registers from max44000 driver.
Best Regards,
Pratik
On Sun, Jul 10, 2016 at 8:09 PM, Jonathan Cameron <jic23@...nel.org> wrote:
> On 10/07/16 14:11, Pratik Prajapati wrote:
>> Including more members.
>>
>> On Sat, Jul 9, 2016 at 5:22 PM, Pratik Prajapati
>> <pratik.prajapati12@...il.com> wrote:
>>> Hi,
> hi Pratik,
>>>
>>> I am trying to add support of adjusting IR led current in vcnl4000
>>> driver (has IR led current register for doing the same).
> This is always a bit of a 'rough' corner when it comes to what interface
> to do it with. Strictly speaking this is typically just a regulator that
> happens to be used for this special purpose. Sometimes they are tightly
> tied together with the input and sometime (on devices with more than one)
> there is no explicit linkage at all.
>
> In this particular case we seem to actually have a high frequency modulated
> LED driver so it's pretty tightly tied to this use.
>>>
>>> Below is what I have done till now:
>>>
>>> 1) Added Current channel in the vcnl4000_channels structure with
>>> separate mask IIO_CHAN_INFO_RAW
>>> 2) Reading the LED current register inside IIO_CURRENT case in vcnl4010_read_raw
>>> 3) Writing to LED current register inside IIO_CURRENT case in vcnl4010_write_raw
>>>
>>> Is this the correct way of setting Current register in IIO subsystem?
> That's about the best option we currently have. This is exactly how it's done
> in the max44000 driver for example.
>
> It's not an interface anyone is terribly happy with so you are welcome to
> suggestion alternatives (easy to add them as an additional interface to
> existing cases - which is why we haven't been that worried about ending up
> with the current less than ideal interface)
> The tight coupling in this particular case might justify something more
> explicitly linked to the proximity channel but as noted above it's not
> always that obvious (see the health/afe parts for example which are way
> too flexible in my view!)
>
> Jonathan
>
>
>>>
>>> Best Regards,
>>> Pratik Prajapati
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
Powered by blists - more mailing lists