[PATCHv3 8/9] ARM: OMAP2+: AM33XX: Basic suspend resume support

[Vaibhav Bedia]

(picking up an old thread, again)

On Thu, Aug 8, 2013 at 7:04 PM, Kevin Hilman <khilman at linaro.org> 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