[PATCH 4/4] ARM: omap2: restore OMAP4 barrier behaviour

[Russell King - ARM Linux]

On Mon, Jul 27, 2015 at 04:23:45PM -0500, Dan Murphy wrote:
> Russell
> 
> On 07/15/2015 12:47 PM, Russell King wrote:
> > +#ifdef CONFIG_OMAP_INTERCONNECT_BARRIER
> > +
> >  /* Used to implement memory barrier on DRAM path */
> >  #define OMAP4_DRAM_BARRIER_VA			0xfe600000
> >  
> > -void __iomem *dram_sync, *sram_sync;
> > +static void __iomem *dram_sync, *sram_sync;
> > +static phys_addr_t dram_sync_paddr;
> > +static u32 dram_sync_size;
> > +
> > +/*
> > + * The OMAP4 bus structure contains asynchrnous bridges which can buffer
> > + * data writes from the MPU. These asynchronous bridges can be found on
> > + * paths between the MPU to EMIF, and the MPU to L3 interconnects.
> > + *
> > + * We need to be careful about re-ordering which can happen as a result
> > + * of different accesses being performed via different paths, and
> > + * therefore different asynchronous bridges.
> > + */
> >  
> > -static phys_addr_t paddr;
> > -static u32 size;
> > +/*
> > + * OMAP4 interconnect barrier which is called for each mb() and wmb().
> > + * This is to ensure that normal paths to DRAM (normal memory, cacheable
> > + * accesses) are properly synchronised with writes to DMA coherent memory
> > + * (normal memory, uncacheable) and device writes.
> > + *
> > + * The mb() and wmb() barriers only operate only on the MPU->MA->EMIF
> > + * path, as we need to ensure that data is visible to other system
> > + * masters prior to writes to those system masters being seen.
> > + *
> > + * Note: the SRAM path is not synchronised via mb() and wmb().
> > + */
> > +static void omap4_mb(void)
> 
> Sorry for the late response but this throws a warning when CONFIG_ARCH_OMAP4
> is not configured.
> 
> arch/arm/mach-omap2/omap4-common.c:85:13: warning: 'omap4_mb' defined but not used [-Wunused-function]

Sorry, I'm going to have to disagree with you and your compiler on this.
This is how the code is structured:

#ifdef CONFIG_OMAP_INTERCONNECT_BARRIER
...
static void omap4_mb(void)
{
        if (dram_sync)
                writel_relaxed(0, dram_sync);
}
...
void __init omap_barriers_init(void)
{
...
        soc_mb = omap4_mb;
}

#endif

So, the definition of omap4_mb(), and the use of the same are both
under the same ifdef.  You can't build omap4_mb() without also building
omap_barriers_init() as well.

So, there's no way that omap4_mb() would be "defined but not used".

I think you have some changes in your kernel which, maybe, place an
ifdef around omap_barriers_init() which _would_ cause the warning you're
seeing if they aren't set.

Also, please trim context before the relevant part to which you're
replying. I almost gave up paging down to see whether there was actually
anything worth replying to.  If there's nothing in the first 50 lines of
the message, it's a waste of space.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.