> >> On the ARM Chromebook tps65090 has two masters: the AP (the main > >> processor running linux) and the EC (the embedded controller). The AP > >> is allowed to mess with FETs but the EC is in charge of charge control. > >> > >> The tps65090 interupt line is routed to both the AP and the EC, which > >> can cause quite a headache. Having two people adjusting masks and > >> acking interrupts is a recipe for disaster. > >> > >> In the shipping kernel we had a hack to have the AP pay attention to > >> the IRQ but not to ack it. It also wasn't supposed to configure the > >> IRQ in any way. That hack allowed us to detect when the device was > >> charging without messing with the EC's state. > >> > >> The current tps65090 infrastructure makes the above difficult, and it > >> was a bit of a hack to begin with. Rather than uglify the driver to > >> support it, just extend the driver's existing notion of "no irq" to > >> the charger. This makes the charger code poll every 2 seconds for AC > >> detect, which is sufficient. > >> > >> Signed-off-by: Doug Anderson <dianders@xxxxxxxxxxxx> > >> --- > >> drivers/mfd/tps65090.c | 14 ++++++-- > >> drivers/power/tps65090-charger.c | 76 +++++++++++++++++++++++++++++++--------- > >> 2 files changed, 70 insertions(+), 20 deletions(-) > > > > For the MFD part: > > Acked-by: Lee Jones <lee.jones@xxxxxxxxxx> > > > > Anton, > > If you are okay with this patch I'd be happy to create an immutable > > branch for you to pull from? > > > > Doug, > > What is the relationship (dependencies) between this and the other > > patches in the set? > > This patch can be applied irrespective of other others in the series. What about the files in the patch? Could you make two separate patches from this one patch and it would still compile okay? I'm _guessing_ the answer is yes? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |