Re: [RFC PATCH] ARM: OMAP4: ID: Improve features detection and check

[Santosh Shilimkar]

On Thursday 01 November 2012 10:36 PM, Nishanth Menon wrote:
> On 22:05-20121101, Santosh Shilimkar wrote:
> > On Thursday 01 November 2012 09:50 PM, ivan.khoronzhuk wrote:
> > > On 11/01/2012 01:35 PM, Santosh Shilimkar wrote:
> > > > On Thursday 01 November 2012 03:53 PM, Ivan Khoronzhuk wrote:
> > > > > Replaces several flags bearing the same meaning. There is no need
> > > > > to set flags due to different omap types here, it can be checked
> > > > > in appropriate places as well.
> > > > >
> > > > > Cc: Tony Lindgren <tony@xxxxxxxxxxx>
> > > > > Cc: Russell King <linux@xxxxxxxxxxxxxxxx>
> > > > > Cc: linux-omap@xxxxxxxxxxxxxxx
> > > > > Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
> > > > > Cc: linux-kernel@xxxxxxxxxxxxxxx
> > > > > Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@xxxxxx>
> > > > > ---

[..]
> > > > > +    if (si_type == OMAP4_SILICON_TYPE_PERFORMANCE)
> > > > > +        omap_features = OMAP4_HAS_PERF_SILICON;
> > > >
> > > > Well the detection isn't for performance/standard but there are some
> > > > features depend on it. For example 1 GHz doesn't DPLL DCC enable feature
> > > > where as 1.2 GHz, 1.5 GHz doesn't need. This is the main reason this
> > > > information is also effused. Have you considered this aspect while
> > > > creating this patch ?
> > > >
> > > > Regards
> > > > Santosh
> > >
> > > I had considered it. There is no dependency on the features.
> > > DCC usage depends on asked frequency on the fly, not from the features.
> > > Depending on "performance/standard" feature the available frequencies
> > > should be chosen in places where they are needed, for example while
> > > initializing OPPs.
> > You are correct about the way DCC is handled in the clock code. Infact
> > all these features like L2CACHE, SGX, IVA etc is more for to display
> > boot messages.
> >
> > > Currently we have several features while it is only one indeed.
> > 1GHz, 1.2GHz, 1.5 GHz are not same since the silicon capability itself
> > is different.
> >
> > git blame tells me that Nishant has sent this update so looping him
> > if above differentiation in boot log helps.
> >
> > Nishant,
> > What's your take on removing above freq prints and marking
> > those silicon as performance silicons as the $subject patch does ?
> >
> > Regards
> > Santosh
> Yes $subject patch is a better approach compared to having freq based
> handling which just increases the number of macros we need to enable
> depending on SoC variants that we spin off the main SoC. This also
> allows us to conserve the features bitfield ahead as well.
>
> I hate to admit, but after a couple of generations of SoC spinoffs,
> my original logic is proving to be was pretty short sighted,
> unfortunately :(
>
> So, approach
> Acked-by: Nishanth Menon <nm@xxxxxx>
Thanks Nishant for clarification and ack.

With the clarification I also like the subject patch.
Feel free add.

Acked-by: Santosh Shilimkar <santosh.shilimkar@xxxxxx>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/