All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Benjamin Drung <benjamin.drung@profitbricks.com>
Cc: "Manuel A. Fernandez Montecelo" <mafm@debian.org>,
	894995@bugs.debian.org,
	List Linux RDMA Mailing <linux-rdma@vger.kernel.org>
Subject: Bug#894995: rdma-core: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)
Date: Fri, 20 Apr 2018 09:31:38 -0600	[thread overview]
Message-ID: <20180420153138.GE30433@ziepe.ca> (raw)
In-Reply-To: <1524139218.4781.9.camel@profitbricks.com>

On Thu, Apr 19, 2018 at 02:00:18PM +0200, Benjamin Drung wrote:
> > I applied the same fix as for many other arches, which is to add the
> > arch to the
> > list of NO_COHERENT_DMA_ARCHS in debian/rules.
> > 
> > I am not sure if support could be added at a later date, but for the
> > time being,
> > seems to be the best way to get it working -- I don't know enough
> > details of the
> > architecture or the assembly language to get the necessary
> > incantations in
> > place.
> 
> RISC-V has a FENCE instruction and the A extension (which is part of
> the G instruction set) provides atomic memory operations. So the
> architecture should provide coherent DMA support. To enable support,
> util/udma_barrier.h needs to be adjusted. I am including
> linux-rdma@vger.kernel.org in the loop for help.

You can't tell from the instruction set if a chip is DMA coherent or
not. It depends how the cache's are designed, and if they have a
'snoop controller' or otherwise.

Generally if *any* DMA coherent implementations exist then we should
add the fences, otherwise better to just not compile the drivers that
have no chance of working.

Jason

      reply	other threads:[~2018-04-20 15:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <152297424964.29286.16311629290309565149.reportbug@reva.itsari.org>
2018-04-19 12:00 ` Bug#894995: rdma-core: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian) Benjamin Drung
2018-04-20 15:31   ` Jason Gunthorpe [this message]

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=20180420153138.GE30433@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=894995@bugs.debian.org \
    --cc=benjamin.drung@profitbricks.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=mafm@debian.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.