On Tue, Feb 17, 2015 at 01:05:07PM +0100, Geert Uytterhoeven wrote: > However, as soon as the da9210 driver will get interrupt support (I wrote > something, based on the da9211 driver) and the da9210 will have an interrupts > property in DTS, the interrupt storm will reappear, irrespectively of the order > in which the two drivers are initialized. Well, there's another problem there - unless things changed since I last looked we don't support shared threaded IRQs. > So far I see only two solutions: > - Add platform code that matches against "renesas,koelsch" (and > "renesas,lager"), and mask the interrupts in both the da9210 and da9063. > This code has to run after the i2c master driver has been initialized, > but before the i2c slave drivers are initialized. > - Handle the masking in the bootloader (u-boot), which already knows how to > reset the board by kicking the da9063. This requires everybody to upgrade > his bootloader, though. > Does anyone have a better solution? We could try to make the code that masks interrupts on error handle screaming shared interrupts a bit more gracefully during bootstrap by shutting things up a bit more aggressively and retrying when something else registers but that just feels like it's going to open up a particularly messy rabbit hole. Of the options you list above the platform code sounds the most palatable. > Question: Is it really the default state of the regulator to not mask > any interrupts? > Or could this have been changed by the bootloader? I couldn't find code related > to that in U-Boot, but as I didn't compile the bootloader myself, I can't be > 100% certain about the source code. It wouldn't surprise me, having talked with designers of analogue chips they can at times have some innovative ideas about interaction with the processor and interrupts in particular. It's also possible that there's some transient condition that occurs during startup that causes the interrupts to be flagged.
Attachment:
signature.asc
Description: Digital signature
