From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Joel Stanley <joel@jms.id.au>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jeremy Kerr <jk@ozlabs.org>,
Christopher Bostic <cbostic@linux.vnet.ibm.com>
Subject: Re: [PATCH 00/15] fsi: Overall improvements and new SBE fifo driver
Date: Sun, 10 Jun 2018 16:46:53 +1000 [thread overview]
Message-ID: <626a3d2bc30dac29c06ab44fb2c56d17095fca51.camel@kernel.crashing.org> (raw)
In-Reply-To: <CACPK8XdvnGHz6Om2RQmgu+7F4h9AEh+Ay=A_b4+3vDGqD4SKbA@mail.gmail.com>
(Greg, see below)
On Tue, 2018-05-29 at 22:00 +0930, Joel Stanley wrote:
> On 29 May 2018 at 11:00, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > This series brings in a number of improvements to our FSI stack
> > (one of the service interfaces for communicating between a BMC chip and
> > our POWER processors).
> >
> > The GPIO based "Soft FSI" performance is significantly improved, and
> > it's reliability as well.
> >
> > The SBE fifo driver provides the interface to the processor "Self Boot
> > Engine"
> >
> > Some of these patches have been simmering for a while in the OpenBMC
> > tree.
>
> I run this series atop of 4.17-rc7 today, and they look solid.
>
> Tested-by: Joel Stanley <joel@jms.id.au>
So how do we proceed ? I have more coming on top of this, but we should
start with getting this series merged.
Greg, should we create a FSI git repo with a 3-member maintainer team
(Jeremy, Chris and myself) and send you pull requests ? Or are you
happy to continue picking up patches ?
We have more stuff to come in there, including support for a HW master
contoller in a future BMC chip, some more slave drivers, etc..
It also looks like the s390 guys might start using some of that as well
(their chips use FSI as well, so far they used our old service
processor which uses an ancient non-uptream set of drivers & stack, but
that's likely to change).
Cheers,
Ben.
> Cheers,
>
> Joel
next prev parent reply other threads:[~2018-06-10 6:47 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-29 1:30 [PATCH 00/15] fsi: Overall improvements and new SBE fifo driver Benjamin Herrenschmidt
2018-05-29 1:30 ` [PATCH 01/15] fsi: gpio: Trace busy count Benjamin Herrenschmidt
2018-05-29 1:30 ` [PATCH 02/15] fsi: gpio: Remove unused 'id' variable Benjamin Herrenschmidt
2018-05-29 1:30 ` [PATCH 03/15] fsi: gpio: Use a mutex to protect transfers Benjamin Herrenschmidt
2018-05-29 1:30 ` [PATCH 04/15] fsi/fsi-master-gpio: Sample input data on different clock phase Benjamin Herrenschmidt
2018-05-29 1:30 ` [PATCH 05/15] fsi/fsi-master-gpio: Add "no-gpio-delays" option Benjamin Herrenschmidt
2018-05-29 1:42 ` Benjamin Herrenschmidt
2018-05-29 1:43 ` [PATCH] dt-bindings: fsi-master-gpio: Document "no-gpio-delays" property Benjamin Herrenschmidt
2018-05-31 17:13 ` Rob Herring
2018-05-29 1:30 ` [PATCH 06/15] fsi/fsi-master-gpio: Reduce turnaround clocks Benjamin Herrenschmidt
2018-05-29 1:30 ` [PATCH 07/15] fsi/fsi-master-gpio: Reduce dpoll clocks Benjamin Herrenschmidt
2018-05-29 1:30 ` [PATCH 08/15] fsi/fsi-master-gpio: Delay sampling of FSI data input Benjamin Herrenschmidt
2018-05-29 1:30 ` [PATCH 09/15] fsi/gpio: Include command build in locked section Benjamin Herrenschmidt
2018-05-29 1:30 ` [PATCH 10/15] fsi/gpio: Use relative-addressing commands Benjamin Herrenschmidt
2018-05-29 1:30 ` [PATCH 11/15] fsi/fsi-master-gpio: Implement CRC error recovery Benjamin Herrenschmidt
2018-05-29 1:30 ` [PATCH 12/15] fsi/fsi-master-gpio: More error handling cleanup Benjamin Herrenschmidt
2018-05-29 1:30 ` [PATCH 13/15] fsi/master-gpio: Replace bit_bit lock with IRQ disable/enable Benjamin Herrenschmidt
2018-05-29 1:30 ` [PATCH 14/15] fsi: scom: Remove PIB reset during probe Benjamin Herrenschmidt
2018-05-29 1:30 ` [PATCH 15/15] fsi/sbefifo: Add driver for the SBE FIFO Benjamin Herrenschmidt
2018-05-29 12:30 ` [PATCH 00/15] fsi: Overall improvements and new SBE fifo driver Joel Stanley
2018-06-10 6:46 ` Benjamin Herrenschmidt [this message]
2018-06-10 6:57 ` Greg Kroah-Hartman
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=626a3d2bc30dac29c06ab44fb2c56d17095fca51.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=cbostic@linux.vnet.ibm.com \
--cc=gregkh@linuxfoundation.org \
--cc=jk@ozlabs.org \
--cc=joel@jms.id.au \
--cc=linux-kernel@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).