* Paul Walmsley <paul@xxxxxxxxx> [110705 18:37]: > cc'ing Aaro > > On Mon, 4 Jul 2011, Tony Lindgren wrote: > > > Also related is the gptimer12 on secure omaps as reported by Aaro. > > This problem is actually worse. In this case it's not just preventing > reset; we must prevent the kernel from using the device at all. My > understanding is also that it's the X-Loader or bootloader -- or more > broadly, secure mode code -- that actually chooses which devices are > protected in this way. In other words, we can't make any automatic > decisions that are based on knowing that a chip is a high-security chip -- > it will need to be defined by the board file :-( > > For this case, we probably need some board file function to tell the hwmod > code to disregard a device completely, to tell the kernel to pretend that > the device does not exist. Yeah that should be done in a generic way. Some shared devices can also be used by a coprocessor like the DSP instead. So basically we want to tell the following from the board file or board specific .dts file: - Device is being used on the board and can be reset and configured. This is the usual case. - Device is being used on the board but can't be reset. This is the case for booting Linux from other operating systems initially where you want to keep the LCD on for debug console. - Device is not being used on the board but can be reset for decent PM. This is often needed in cases where the bootloader just enables all the clocks. - Device is reserved by secure mode or a coprocessor. In this case the device can't be reset. So I guess that makes the flags noreset, disabled and unavailable? For the devices with no special flags we would then reset the device. Regards, Tony -- 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
