On Mon, Apr 18, 2016 at 08:36:19PM +0100, Jonathan Cameron wrote:
> On 18/04/16 13:34, Mark Brown wrote:
> > Yes. I have to say that you are the first person I've encountered who
> > has been confused by this, I'm not sure why you'd expect writes to be
> > discarded.
> It confused me too :) To
On 18/04/16 11:32, Mark Brown wrote:
> On Sun, Apr 17, 2016 at 09:36:10AM +0100, Jonathan Cameron wrote:
>> On 11/04/16 16:08, Crestez Dan Leonard wrote:
>
> Please leave blank lines between paragraphs, it makes things much easier
> to read.
>
>>> Would it be
>>> acceptable to just expand the REG
On 18/04/16 13:34, Mark Brown wrote:
> On Mon, Apr 18, 2016 at 03:15:54PM +0300, Crestez Dan Leonard wrote:
>
>> As a further clarification: regmap_write will write to hardware even if
>> the cache is known to be up-to-date and no matter the regcache_type. Did
>> I understand this correctly?
>
>>
On Mon, Apr 18, 2016 at 03:15:54PM +0300, Crestez Dan Leonard wrote:
> As a further clarification: regmap_write will write to hardware even if
> the cache is known to be up-to-date and no matter the regcache_type. Did
> I understand this correctly?
> I'm basing this on reading the code, it seems
On 04/18/2016 01:32 PM, Mark Brown wrote:
> On Sun, Apr 17, 2016 at 09:36:10AM +0100, Jonathan Cameron wrote:
>> On 11/04/16 16:08, Crestez Dan Leonard wrote:
>>> I used REGCACHE_FLAT because my device has a very small number of
>>> registers and I assume it uses less memory. Honestly it would make
On 04/18/2016 12:32 PM, Mark Brown wrote:
[...]
This always seems like a good idea, but tends to cause issues.
FLAT is really only meant for very high performance devices, you
are probably better with something else here. If you are doing this
deliberately to make the below wri
On Sun, Apr 17, 2016 at 09:36:10AM +0100, Jonathan Cameron wrote:
> On 11/04/16 16:08, Crestez Dan Leonard wrote:
Please leave blank lines between paragraphs, it makes things much easier
to read.
> > Would it be
> > acceptable to just expand the REGMASK_* into a large or-ing of (1 <<
> > MAX44000
On 11/04/16 16:08, Crestez Dan Leonard wrote:
> On 04/10/2016 04:12 PM, Jonathan Cameron wrote:
>> On 07/04/16 20:48, Peter Meerwald-Stadler wrote:
>>>
This just adds support for reporting illuminance with default settings.
All default registers are written on probe because the devic
On 04/10/2016 04:12 PM, Jonathan Cameron wrote:
On 07/04/16 20:48, Peter Meerwald-Stadler wrote:
This just adds support for reporting illuminance with default settings.
All default registers are written on probe because the device otherwise
lacks a reset function.
comments below
Mostly fin
On 07/04/16 20:48, Peter Meerwald-Stadler wrote:
>
>> This just adds support for reporting illuminance with default settings.
>>
>> All default registers are written on probe because the device otherwise
>> lacks a reset function.
>
> comments below
Mostly fine, but a few corners need cleaning up
> This just adds support for reporting illuminance with default settings.
>
> All default registers are written on probe because the device otherwise
> lacks a reset function.
comments below
> Signed-off-by: Crestez Dan Leonard
> ---
> drivers/iio/light/Kconfig| 11 ++
> drivers/iio/lig
This just adds support for reporting illuminance with default settings.
All default registers are written on probe because the device otherwise
lacks a reset function.
Signed-off-by: Crestez Dan Leonard
---
drivers/iio/light/Kconfig| 11 ++
drivers/iio/light/Makefile | 1 +
drivers/iio
12 matches
Mail list logo
