Tony Lindgren had written, on 07/09/2010 02:08 AM, the following:
* Nishanth Menon <nm@xxxxxx> [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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
