| Message ID | 5c7f9044fefed8bc0e4ca5688801ffa379f38f62.camel@kernel.crashing.org |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
| Series | [GIT,PULL,v2] FSI updates for 4.17 | expand |
On Tue, Jun 12, 2018 at 08:54:39PM +1000, Benjamin Herrenschmidt wrote: > Hi Greg ! > > There are a first round of updates of the FSI stack, aiming at reducing/removing > he gap with the OpenBMC tree and a first step in getting dependent drivers > upstream. > > These changes significantly improve the FSI bitbanging driver performance > and reliability, and add the new "sbefifo" driver for communicating with > the POWER9 Self Boot Engine (which will be needed for some upcoming > additional drivers). > > These were posted to the list as patches a couple of weeks ago and were > prior to that tested in the OpenBMC tree and CI. Some subsequent driver > work depends on some of these, so merging early is probably the best. Yeah, but as they are not "regression fixes", I'll put them into my -next branch for merging with 4.19-rc1. I'll do that once 4.18-rc1 is released, can't touch my trees until that happens. thanks, greg k-h
On Tue, 2018-06-12 at 13:18 +0200, Greg Kroah-Hartman wrote: > On Tue, Jun 12, 2018 at 08:54:39PM +1000, Benjamin Herrenschmidt wrote: > > Hi Greg ! > > > > There are a first round of updates of the FSI stack, aiming at reducing/removing > > he gap with the OpenBMC tree and a first step in getting dependent drivers > > upstream. > > > > These changes significantly improve the FSI bitbanging driver performance > > and reliability, and add the new "sbefifo" driver for communicating with > > the POWER9 Self Boot Engine (which will be needed for some upcoming > > additional drivers). > > > > These were posted to the list as patches a couple of weeks ago and were > > prior to that tested in the OpenBMC tree and CI. Some subsequent driver > > work depends on some of these, so merging early is probably the best. > > Yeah, but as they are not "regression fixes", I'll put them into my > -next branch for merging with 4.19-rc1. I'll do that once 4.18-rc1 is > released, can't touch my trees until that happens. We are in regression only mode even before -rc1 these days ? including for code that is basically completely unused upstream (which is what this is trying to fix) ? :-) That's rather full-on ... Anyway no biggie, it will just slow down some getting some of the other drivers I suppose, though we can always explicitly list the dependency on this tag to work around it. Cheers, Ben.
On Tue, Jun 12, 2018 at 09:25:11PM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2018-06-12 at 13:18 +0200, Greg Kroah-Hartman wrote: > > On Tue, Jun 12, 2018 at 08:54:39PM +1000, Benjamin Herrenschmidt wrote: > > > Hi Greg ! > > > > > > There are a first round of updates of the FSI stack, aiming at reducing/removing > > > he gap with the OpenBMC tree and a first step in getting dependent drivers > > > upstream. > > > > > > These changes significantly improve the FSI bitbanging driver performance > > > and reliability, and add the new "sbefifo" driver for communicating with > > > the POWER9 Self Boot Engine (which will be needed for some upcoming > > > additional drivers). > > > > > > These were posted to the list as patches a couple of weeks ago and were > > > prior to that tested in the OpenBMC tree and CI. Some subsequent driver > > > work depends on some of these, so merging early is probably the best. > > > > Yeah, but as they are not "regression fixes", I'll put them into my > > -next branch for merging with 4.19-rc1. I'll do that once 4.18-rc1 is > > released, can't touch my trees until that happens. > > We are in regression only mode even before -rc1 these days ? including > for code that is basically completely unused upstream (which is what > this is trying to fix) ? :-) That's rather full-on ... For code that goes into -rc1, it has to be in linux-next _BEFORE_ -final comes out. That's been the rule for years, you should know that... > Anyway no biggie, it will just slow down some getting some of the other > drivers I suppose, though we can always explicitly list the dependency > on this tag to work around it. There should not be a rush here, remember, kernel development does not have deadlines :) greg k-h
On Tue, 2018-06-12 at 13:44 +0200, Greg Kroah-Hartman wrote: > > > We are in regression only mode even before -rc1 these days ? including > > for code that is basically completely unused upstream (which is what > > this is trying to fix) ? :-) That's rather full-on ... > > For code that goes into -rc1, it has to be in linux-next _BEFORE_ -final > comes out. That's been the rule for years, you should know that... Oh I know and I also know that the rule was always somewhat flexible for "new" drivers ;-) But heh, it's not biggie. > > Anyway no biggie, it will just slow down some getting some of the other > > drivers I suppose, though we can always explicitly list the dependency > > on this tag to work around it. > > There should not be a rush here, remember, kernel development does not > have deadlines :) Sort-of, it does make things difficult to have so much crap piling up out of tree or in vendor trees as you well know, so the faster that pile is sorted, the better everybody is. But I can deal with the dependencies for 4.19 (assuming we get the 2 or 3 other drivers I want to see upstream lined up as well in the next few weeks). Cheers, Ben.
On Tue, Jun 12, 2018 at 08:54:39PM +1000, Benjamin Herrenschmidt wrote: > Hi Greg ! > > There are a first round of updates of the FSI stack, aiming at reducing/removing > he gap with the OpenBMC tree and a first step in getting dependent drivers > upstream. > > These changes significantly improve the FSI bitbanging driver performance > and reliability, and add the new "sbefifo" driver for communicating with > the POWER9 Self Boot Engine (which will be needed for some upcoming > additional drivers). > > These were posted to the list as patches a couple of weeks ago and were > prior to that tested in the OpenBMC tree and CI. Some subsequent driver > work depends on some of these, so merging early is probably the best. > > The following changes since commit 8efcf34a263965e471e3999904f94d1f6799d42a: > > Merge tag 'armsoc-late' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2018-06-11 18:19:45 -0700) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/benh/linux-fsi.git tags/fsi-updates-2018-06-12 Sorry for the delay, now merged. greg k-h
Hi Greg ! There are a first round of updates of the FSI stack, aiming at reducing/removing he gap with the OpenBMC tree and a first step in getting dependent drivers upstream. These changes significantly improve the FSI bitbanging driver performance and reliability, and add the new "sbefifo" driver for communicating with the POWER9 Self Boot Engine (which will be needed for some upcoming additional drivers). These were posted to the list as patches a couple of weeks ago and were prior to that tested in the OpenBMC tree and CI. Some subsequent driver work depends on some of these, so merging early is probably the best. The following changes since commit 8efcf34a263965e471e3999904f94d1f6799d42a: Merge tag 'armsoc-late' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2018-06-11 18:19:45 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/benh/linux-fsi.git tags/fsi-updates-2018-06-12 for you to fetch changes up to 9f4a8a2d7f9d71093f41c4bb0ef8707e8145bad3: fsi/sbefifo: Add driver for the SBE FIFO (2018-06-12 14:05:39 +1000) ---------------------------------------------------------------- FSI updates and sbefifo driver ---------------------------------------------------------------- Andrew Jeffery (2): fsi: gpio: Trace busy count fsi: gpio: Remove unused 'id' variable Benjamin Herrenschmidt (8): fsi/fsi-master-gpio: Sample input data on different clock phase fsi/fsi-master-gpio: Add "no-gpio-delays" option fsi/fsi-master-gpio: Reduce turnaround clocks fsi/fsi-master-gpio: Reduce dpoll clocks fsi/fsi-master-gpio: Delay sampling of FSI data input fsi/fsi-master-gpio: Implement CRC error recovery fsi/fsi-master-gpio: More error handling cleanup fsi/sbefifo: Add driver for the SBE FIFO Eddie James (1): fsi: scom: Remove PIB reset during probe Jeremy Kerr (4): fsi: gpio: Use a mutex to protect transfers fsi/gpio: Include command build in locked section fsi/gpio: Use relative-addressing commands fsi/master-gpio: Replace bit_bit lock with IRQ disable/enable arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 1 + arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts | 1 + arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts | 1 + drivers/fsi/Kconfig | 7 + drivers/fsi/Makefile | 1 + drivers/fsi/fsi-master-gpio.c | 349 ++++++++++++---- drivers/fsi/fsi-sbefifo.c | 1005 +++++++++++++++++++++++++++++++++++++++++++++++ drivers/fsi/fsi-scom.c | 8 - include/linux/fsi-sbefifo.h | 33 ++ include/trace/events/fsi_master_gpio.h | 43 ++ 10 files changed, 1362 insertions(+), 87 deletions(-) create mode 100644 drivers/fsi/fsi-sbefifo.c create mode 100644 include/linux/fsi-sbefifo.h