From mboxrd@z Thu Jan  1 00:00:00 1970
From: jason@lakedaemon.net (Jason Cooper)
Date: Fri, 27 Dec 2013 12:46:19 -0500
Subject: [PATCH RFCv1 0/6] ARM: mvebu: coherency support improvements
In-Reply-To: <20131227173213.GS19878@titan.lakedaemon.net>
References: <1388067176-18177-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <20131227173213.GS19878@titan.lakedaemon.net>
Message-ID: <20131227174619.GU19878@titan.lakedaemon.net>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On Fri, Dec 27, 2013 at 12:32:13PM -0500, Jason Cooper wrote:
> Thomas,
> 
> On Thu, Dec 26, 2013 at 03:12:50PM +0100, Thomas Petazzoni wrote:
> > Jason, Gregory, Andrew, Sebastian,
> > 
> > Here is a set of patches that make some changes to the mach-mvebu
> > coherency code, and the way the mvebu-mbus driver determines whether
> > hardware I/O coherency is enabled or not.
> > 
> > These changes are proposed in preparation to the introduction of the
> > support for more recent SOCs in mach-mvebu, which have a slightly
> > different coherency fabric (hence the need for different compatible
> > strings) and different constraints to be able to enable the I/O
> > coherency (not only the coherency fabric must be available, but the
> > kernel must be running in CONFIG_SMP).
> > 
> > Moreover, the mvebu-mbus driver was directly poking into the DT to
> > find whether a coherency fabric node was available or not, to
> > determine if I/O coherency is enabled or not. However, with the new
> > constraint that CONFIG_SMP must be enabled on some SOCs to get I/O
> > coherency, the solution of having mvebu-mbus directly poke into the DT
> > is not longer appropriate. This patch set therefore changes the
> > mvebu_mbus_dt_init() function call to take an additional boolean
> > argument telling whether the system is running in I/O coherent mode or
> > not.
> > 
> > I've for now marked those patches as RFC, to indicate that they are
> > clearly open for discussion. For example, I'm still wondering if I
> > should not introduce separate compatible strings
> > marvell,armada-370-coherency-fabric and
> > marvell,armada-xp-coherency-fabric for Armada 370 and Armada XP
> > respectively instead of using marvell,armada-370-coherency-fabric for
> > both. Our experience has shown that we often initially believe that a
> > given hardware unit is similar between SOCs, and then later discover
> > that there are in fact some slight differences, which should have
> > called for different compatible strings from the beginning.
> > 
> > Best regards,
> > 
> > Thomas
> > 
> > Thomas Petazzoni (6):
> >   ARM: mvebu: prepare coherency code to support more SOCs
> >   ARM: mvebu: add a coherency_available() call
> >   bus: mvebu: pass the coherency availability information at init time
> >   ARM: mvebu: use of_find_matching_node_and_match() in coherency.c
> >   ARM: mvebu: update Armada 370/XP DT to use new coherency compatible
> >     string
> >   ARM: mvebu: update coherency fabric DT binding documentation
> > 
> >  .../devicetree/bindings/arm/coherency-fabric.txt   | 19 +++--
> >  arch/arm/boot/dts/armada-370-xp.dtsi               |  2 +-
> >  arch/arm/mach-kirkwood/board-dt.c                  |  2 +-
> >  arch/arm/mach-mvebu/armada-370-xp.c                |  2 +-
> >  arch/arm/mach-mvebu/coherency.c                    | 80 ++++++++++++++++------
> >  arch/arm/mach-mvebu/coherency.h                    |  1 +
> >  drivers/bus/mvebu-mbus.c                           | 11 +--
> >  include/linux/mbus.h                               |  2 +-
> >  8 files changed, 79 insertions(+), 40 deletions(-)
> 
> How is this different than the RFC v1 I just looked over?

And now that I've made it past my inbox and to the list emails, it's
rather obvious. ;-)

thx,

Jason.