[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 at atomide.com>
>>>>> Cc: Russell King <linux at arm.linux.org.uk>
>>>>> Cc: linux-omap at vger.kernel.org
>>>>> Cc: linux-arm-kernel at lists.infradead.org
>>>>> Cc: linux-kernel at vger.kernel.org
>>>>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk at ti.com>
>>>>> ---

[..]
>>>>> +    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 at ti.com>
>
Thanks Nishant for clarification and ack.

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

Acked-by: Santosh Shilimkar <santosh.shilimkar at ti.com>