From: gregkh@xxxxxxxxxxxxxxxxxxx
> > ...
> > > +#ifdef
> > > +static inline void imx28_ci_writel(u32 val, volatile void __iomem *addr)
> > > +{
> > > + __asm__ ("swp %0, %0, [%1]" : : "r"(val), "r"(addr));
> > > +}
> > > +#else
> > > +static inline void imx28_ci_writel(u32 val, volatile void __iomem *addr)
> > > +{
> > > +}
> > > +#endif
> > > +
> > > +static inline void __hw_write(struct ci_hdrc *ci, u32 val,
> > > + void __iomem *addr)
> > > +{
> > > + if (ci->imx28_write_fix)
> > > + imx28_ci_writel(val, addr);
> > > + else
> > > + iowrite32(val, addr);
> > > +}
> > > +
> >
> > This code ought to be defensive against 'imx28_write_fix' being
> > set when the kernel isn't compiled with CONFIG_SOC_IMX28.
> > This can easily be done by changing the #else block to do an iowrite().
>
> You missed the long email thread we just had about this earlier in the
> week...
No - I read most of it, I even commented earlier than the alternate
definition of imx28_ci_writel() should be iowrite32().
> > It is worth looking to see if the compiler manages to optimise away
> > the 'if' test in this case. It might do better if a #define is used
> > instead of the inline function.
>
> It shouldn't make a difference, gcc should optimize it away.
I've seen differences between the optimisations performed on
#defines and inline functions.
#defines tend to optimise slightly better - probably because they
get some optimisations before code generation.
inline functions do have better type checking - especially useful
if they contain casts or local variables.
I've also had to use #defines so I can add an asm statement
containing an asm comment that includes __LINE__ in order to stop
gcc tail-merging code (I didn't want the clock cycles taken by
the extra branch instruction).
Getting static branch prediction right can make a significant difference.
Although each branch is only a few clocks they can soon add up.
Protocol stack code can easily be dominated by conditionals,
removing pipeline stalls can easily speed things up by a measurable 10%.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
