[Letux-kernel] [Kernel] Pyra: is31fl319x V2 driver (RGB-LEDs)

[H. Nikolaus Schaller]

> Am 23.06.2016 um 18:48 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> Hi,
> I did have this driver for a while on my to-do list time to finalise the feedbacks I got
> for V1 from LKML.
> 
> The only unprocessed feedback was to use a regmap for optimizing the
> i2c traffic and solving the issue that we must read back all LED brightness
> values to determine if the chip can be shut down. But there is no i2c read
> response for this chip. So regmap should cache the last value written.
> 
> With the lastest patch It - almost - works like with our own hacks of V1...
> 
> Only problem seems how to correctly setup the regmap so that it never
> really tries to read the chip but return the last value that was written...
> 
> If I return false for readable_reg I get an errno = -5 for all reads.
> If I return true, I get:
> 
> [   13.353654] leds-is31fl319x 4-0064: is31fl319x_brightness_set read ret=-11 [1]: 0
> 
> [   27.661668] leds-is31fl319x 4-0064: is31fl319x_brightness_set read ret=-110 [1]: 0
> 
> which means that the regmap *is* trying to read the chip instead of the cache. This
> times out the bus:
> 
> [   27.641615] omap_i2c 4807c000.i2c: controller timed out
> 
> Such timeouts lead to kernel stalls if there are led triggers (system is flooded
> by unprocessed write requests to the chip).
> 
> 'top' revealed the highest activity process:
> 
>  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
>  824 root     -51   0       0      0      0 R  41.1  0.0   0:44.59 irq/299-4807c00 
> 
> which is indeed the i2c interrupt for the bus where the led driver is connected to.
> 
> Please can someone look over the code to spot issues?
> 
> http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=drivers/leds/leds-is31fl319x.c;h=05f89a27a568c1f9a5c55917ca72e34ce905760c;hb=0e74d2f7ab126d4a1b1a6cc2cd082b0a5fc96a5f

I think I have found the problem. regmap_read returns errno = -5 if the
register cache access fails.

And it fails if there is no cache and the register is marked as not readable.

What I didn't expect is that the default is to have *no cache*.

And some examples of regmap based drivers seem to run w/o cache on
i2c or I would have spotted this line:

	.cache_type = REGCACHE_FLAT,

which makes the difference :)

I would give away a kingdom for better documentation and how-tos for kernel
APIs...

BR,
Nikolaus