On Mon, May 11, 2015 at 10:19 AM, Felipe Balbi <balbi@xxxxxx> wrote: > >> in my opinion, doing a temporary hack in upstream kernel is not an >> elegant approach. I suggest helping review and approving Viresh's new > > however this is not a hack, right ? If we get rid of OPP_NITRO and > OPP_TURBO, then we will more than likely always be dealing with safe > OPPs (yeah, I need to confirm this since it's not on public TRM, so as > of now, take this statement with a grain of salt :-), moreover, even > though we're trying to change opp bindings, the current situation is > still very much accepted and will remain valid even after changing > binding :-) yes - if we do have a documented subset of OPPs that are valid for all "variants" of AM437x, we could add that in using the legacy bindings, but, we will have to do a transition over to the new bindings when they are finalized to support all OPPs appropriately. > Not to mention that people using AM43xx today might be using it under > invalid OPPs and decreasing silicon life; I'd assume that's a very > urgent detail to sort out. While I do agree that there is always a debate between fixing things in kernel for bootloader issues, but it does not mean that we should just postpone fixing the bootloader in this case - since, at this very moment, we are already in broken configuration - example sitting on a bootloader shell does have the same impact we have at this time. Lets try to help Viresh in getting his series sorted out meanwhile - maybe others can help as well :( --- Regards, Nishanth Menon -- 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
