From: jason@lakedaemon.net (Jason Cooper)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFCv1 0/6] ARM: mvebu: coherency support improvements
Date: Fri, 27 Dec 2013 12:46:19 -0500 [thread overview]
Message-ID: <20131227174619.GU19878@titan.lakedaemon.net> (raw)
In-Reply-To: <20131227173213.GS19878@titan.lakedaemon.net>
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.
next prev parent reply other threads:[~2013-12-27 17:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-26 14:12 [PATCH RFCv1 0/6] ARM: mvebu: coherency support improvements Thomas Petazzoni
2013-12-26 14:12 ` [PATCH RFCv1 1/6] ARM: mvebu: prepare coherency code to support more SOCs Thomas Petazzoni
2013-12-26 14:12 ` [PATCH RFCv1 2/6] ARM: mvebu: add a coherency_available() call Thomas Petazzoni
2013-12-26 14:12 ` [PATCH RFCv1 3/6] bus: mvebu: pass the coherency availability information at init time Thomas Petazzoni
2013-12-26 14:12 ` [PATCH RFCv1 4/6] ARM: mvebu: use of_find_matching_node_and_match() in coherency.c Thomas Petazzoni
2013-12-26 14:12 ` [PATCH RFCv1 5/6] ARM: mvebu: update Armada 370/XP DT to use new coherency compatible string Thomas Petazzoni
2013-12-26 14:12 ` [PATCH RFCv1 6/6] ARM: mvebu: update coherency fabric DT binding documentation Thomas Petazzoni
2013-12-27 17:32 ` [PATCH RFCv1 0/6] ARM: mvebu: coherency support improvements Jason Cooper
2013-12-27 17:46 ` Jason Cooper [this message]
2013-12-27 17:55 ` Jason Cooper
[not found] <1388067146-18111-1-git-send-email-thomas.petazzoni@free-electrons.com>
[not found] ` <20131226160831.GB19323@lunn.ch>
[not found] ` <20131226171302.3409b096@skate>
[not found] ` <20131226162931.GD19323@lunn.ch>
2013-12-27 17:55 ` Jason Cooper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131227174619.GU19878@titan.lakedaemon.net \
--to=jason@lakedaemon.net \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox