public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
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:32:13 -0500	[thread overview]
Message-ID: <20131227173213.GS19878@titan.lakedaemon.net> (raw)
In-Reply-To: <1388067176-18177-1-git-send-email-thomas.petazzoni@free-electrons.com>

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?

thx,

Jason.

  parent reply	other threads:[~2013-12-27 17:32 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 ` Jason Cooper [this message]
2013-12-27 17:46   ` [PATCH RFCv1 0/6] ARM: mvebu: coherency support improvements Jason Cooper
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=20131227173213.GS19878@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