Re: [PATCH 1/2] arm: boot: dts: am4372: add operating points

[Felipe Balbi <balbi@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]

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@ti.com> 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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]