(picking up an old thread, again) On Thu, Aug 8, 2013 at 7:04 PM, Kevin Hilman <khilman@xxxxxxxxxx> wrote: > > I disagree here. I'm a firmware minimalist, and hiding bugs like this > in the firmware is wrong when Linux is otherwise managing these devices. > It also imposes criteria on the firmware of future SoCs that doesn't > belong there either. IMO, the only stuff the firmware should do is what > Linux *cannot* do. > > Remember, this only needs to happen when there isn't a driver for these > devices. Should we communicate to the firmware that the OS has no > driver, so please enable the hack? I think not. > Agreed on not hiding the bugs in the firmware. Moreover, M3 can't access the IPs in PER domain which is where the bad modules are, so the h/w doesn't support such hackery (+1 for the h/w after all the -1's that it gets ;) [...] >>> That being said, IMO, the kernel (specifically omap_device) should >>> handle this, and it should be rather easy to do in the omap_device layer >>> and keep the SoC suspend/resume core code simple and ignorant of these >>> "quirks." >>> >>> AFAICT, there's no reason these quirks need to be dealt with immediatly >>> on suspend. A slight delay should be fine, as long as it's before the >>> next suspend/idle attempt, right? >>> >>> Given that, what we need to do (and by we, I mean you) is to flag all >>> broken IP blocks, and let omap_device handle them in a suspend/resume >>> notifier (c.f. register_pm_notifier() and PM_POST_SUSPEND.) >> >> yes - that is the alternate that comes to mind. > > In the earlier reviews of this series (many months ago now), I > complained about the presence of this device specific handling in the > core MPU PM code. I'm somewhat troubled by the fact that nobody explored > alternatives that so easily come to mind. > My bad. I was thinking along those lines [1] but after the suggestion on using the driver bound status i just went with that suggestion in the dumbest possible manner. Regards, Vaibhav [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/129676.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
