HI, On Mon, May 11, 2015 at 11:46:13AM -0500, Nishanth Menon wrote: > 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. sounds fair to me. > > 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. agreed, I'll cook up a patch for bootloader too. > Lets try to help Viresh in getting his series sorted out meanwhile - > maybe others can help as well :( sure. -- balbi
Attachment:
signature.asc
Description: Digital signature
