* H. Nikolaus Schaller hns@goldelico.com [160215 11:30]:
Am 15.02.2016 um 19:20 schrieb Tony Lindgren tony@atomide.com: For your charger issue, see also thread "tvp5150 regression after commit 9f924169c035". Maybe reverting commit 9f924169c035 ("i2c: always enable RuntimePM for the adapter device") also helps with the charger issue?
I have not the impression that I2C plays a role.
OK, only some bq24* chips have I2C control.
So it appears to do what ti,hwmod = "mmc4" should also do if I understand correctly... This is why I am wondering where the hwmod registers are really written. I would try to add a printk to see if they are. Or are not.
Sounds like you need to debug that one further..
I have done (see above) and enable/idle is working well. It is just not used by some higher level...
Sorry I guess I don't follow without seeing what you patched here..
Maybe I just misread
http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mmc/m...
that I have to explicitly specify
&mmc4 { broken-cd; } and omitting the cd-gpio is not sufficient to enable the polling mechanism...
Will try that asap.
That sounds broken if that's the case :)
Another, new topic is the twl6040 which I have done experiments today. The chip is now found and responding and basically initialized because it is listed by aplay -l.
But twl6040-vibra.c seems to have at least 3 significant bugs. One even a NULL pointer dereference which I could trace back to a patch from 3.8 to 3.9... I have fixes but the motor still does not move. Well, Rome wasn't built in a day.
And when trying to aplay or run a rumble effect, I get interrupt and lock problem warnings from the kernel.
That could also be a hardware effect of our board since we have almost exactly copied the connection scheme of the twl6040 from the evm. But there may be a hidden mistake since we are just starting the hardware validation of this area.
Heh OK :)
Regards,
Tony