Re: [PATCH 2/5] omap: Implement common omap_has_feature

[Nishanth Menon <nm@ti.com>]

Tony Lindgren had written, on 07/09/2010 02:08 AM, the following:
> * Nishanth Menon <nm@ti.com> [100708 17:46]:
>> Tony Lindgren had written, on 07/08/2010 04:37 AM, the following:
>>> @@ -112,6 +114,12 @@ void omap_get_die_id(struct omap_die_id *odi)
>>> 	odi->id_3 = read_tap_reg(OMAP_TAP_DIE_ID_3);
>>> }
>>> +u32 omap2_has_feature(u32 feat_mask)
>>> +{
>>> +	/* REVISIT: Add necessary omap2 feature tests here */
>>> +	return ((feat_mask & omap_features) == feat_mask);
>>> +}
>>> +
>> I did consider this path initially,
>> a) Additional functional call overhead here. some of the calls to
>> has_feature() will get called through pretty active paths, we would
>> like it to be minimized to compile time optimized inline function as
>> much as possible.(no reason why this cant me a inline macro in
>> cpu.h?) -
> 
> Well it should not matter how slow this code is, it should only be
> used to initialize things during __init.
> 
> Any code doing detection after initialization is wrong.
couple of reasons why this may not make sense:
a) drivers can be modules -e.g. lets say dss driver would like to know 
if vrfb OR tiler is used -> __init wont make sense
b) has_feature could be used as part of data flow to make decision what 
is to be done.

e.g.

lets say dma chaining as a feature OR dma list as a feature, we should 
allow for usage such as the following:
int chain_dma(...)
{
	if (!omap_has_feature(OMAP_HAS_DMA_CHAINING)) {
		return -EINVAL;
	}
}

this means that we would prefer these kind of path to be high 
performance paths (data paths) - aka inline functions make more sense 
than incurring a function call overhead.

-- 
Regards,
Nishanth Menon