[PATCH V3 0/2] AMD NTB V3 changes

[PATCH V3 0/2] AMD NTB V3 changes

[Xiangliang Yu]

Main changes in V3
1. Remove all power managment related code.
2. Put makefile and kconfig changes in first patch.
3. Call readl/writel directly, not use macros to hide it.

Xiangliang Yu (2):
  NTB: Add AMD PCI-Express NTB driver
  NTB: Add support for flush request interface

 drivers/ntb/hw/Kconfig          |    1 +
 drivers/ntb/hw/Makefile         |    1 +
 drivers/ntb/hw/amd/Kconfig      |    7 +
 drivers/ntb/hw/amd/Makefile     |    1 +
 drivers/ntb/hw/amd/ntb_hw_amd.c | 1182 +++++++++++++++++++++++++++++++++++++++
 drivers/ntb/hw/amd/ntb_hw_amd.h |  249 +++++++++
 include/linux/ntb.h             |   22 +
 7 files changed, 1463 insertions(+)
 create mode 100644 drivers/ntb/hw/amd/Kconfig
 create mode 100644 drivers/ntb/hw/amd/Makefile
 create mode 100644 drivers/ntb/hw/amd/ntb_hw_amd.c
 create mode 100644 drivers/ntb/hw/amd/ntb_hw_amd.h

-- 
1.9.1

RE: [PATCH V3 0/2] AMD NTB V3 changes

[Allen Hubbe]

> From: Xiangliang Yu <Xiangliang.Yu@amd.com>
> 
> Main changes in V3
> 1. Remove all power managment related code.

Can you send the third patch with the power management code?  I think it is important functionality.

Furthermore, a review of the power management patch will help with getting the flush patch accepted.  If the power management patch is reviewed and acked as is, the flush patch is probably ok, too, as is.  If there are changes to power management that are also applicable to the flush patch, it would be good to keep it all consistent when adding the functionality to the api.

> 2. Put makefile and kconfig changes in first patch.
> 3. Call readl/writel directly, not use macros to hide it.

I think this is almost ready.  See comments in NTB: Add AMD PCI-Express NTB driver.

Allen

RE: [PATCH V3 0/2] AMD NTB V3 changes

[Yu, Xiangliang]

> > From: Xiangliang Yu <Xiangliang.Yu@amd.com>
> >
> > Main changes in V3
> > 1. Remove all power managment related code.
> 
> Can you send the third patch with the power management code?  I think it is
> important functionality.

Actually, I have answered the question in V2 comments. Now again, 
I want to submitted all power management related code if runtime part is ready.

> Furthermore, a review of the power management patch will help with
> getting the flush patch accepted.  If the power management patch is
> reviewed and acked as is, the flush patch is probably ok, too, as is.  If there
> are changes to power management that are also applicable to the flush patch,
> it would be good to keep it all consistent when adding the functionality to the
> api.

I want to add flush function into ntb_transport.c, but I can't verify the implementation
Because hardware is not ready.  So I just define a interface this time for future use.
I notice there are lot of interface that hasn't been used in ntb.h.

RE: [PATCH V3 0/2] AMD NTB V3 changes

[Allen Hubbe]

> From: Yu, Xiangliang <Xiangliang.Yu@amd.com>

> I want to add flush function into ntb_transport.c, but I can't verify
> the implementation

Ok.  That's a good reason to hold back the flush mechanism: it's not been tested.

Nak (for now): [PATCH V3 2/2] NTB: Add support for flush request interface

Don't give up.  Please keep working on this, and the power management patch, to get them reviewed and accepted.  It's your choice whether or not to submit the patches, and when.  I'd encourage you to do it early, rather than delay.

Allen

Re: [PATCH V3 0/2] AMD NTB V3 changes

[Jon Mason]

On Fri, Jan 15, 2016 at 12:12:24PM -0500, Allen Hubbe wrote:
> > From: Yu, Xiangliang <Xiangliang.Yu@amd.com>
> 
> > I want to add flush function into ntb_transport.c, but I can't verify
> > the implementation
> 
> Ok.  That's a good reason to hold back the flush mechanism: it's not been tested.
> 
> Nak (for now): [PATCH V3 2/2] NTB: Add support for flush request interface
> 
> Don't give up.  Please keep working on this, and the power management patch, to get them reviewed and accepted.  It's your choice whether or not to submit the patches, and when.  I'd encourage you to do it early, rather than delay.

I'd like to echo Allen's comment above.  Do not give up.  This code is
very close to being accepted (once the issues that Allen and I pointed
out are addressed).  If you can get us another version on/before
Wednesday, it should make the 4.5 release (assuming it is acceptable
and the wdinow is not closed prematurely).

Thanks for all of your hard work (and many thanks to Allen for his
reviews of the code as well).
- Jon


> 
> Allen
> 
> -- 
> You received this message because you are subscribed to the Google Groups "linux-ntb" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-ntb+unsubscribe@googlegroups.com.
> To post to this group, send email to linux-ntb@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/linux-ntb/000001d14fb7%24e7981bd0%24b6c85370%24%40emc.com.
> For more options, visit https://groups.google.com/d/optout.

RE: [PATCH V3 0/2] AMD NTB V3 changes

[Yu, Xiangliang]

> Nak (for now): [PATCH V3 2/2] NTB: Add support for flush request interface
> 
> Don't give up.  Please keep working on this, and the power management
> patch, to get them reviewed and accepted.  It's your choice whether or not
> to submit the patches, and when.  I'd encourage you to do it early, rather
> than delay.

I'll re-submit the patch and PM patch in next time when all code is ready and 
To be tested.

RE: [PATCH V3 0/2] AMD NTB V3 changes

[Yu, Xiangliang]

> > > I want to add flush function into ntb_transport.c, but I can't
> > > verify the implementation
> >
> > Ok.  That's a good reason to hold back the flush mechanism: it's not been
> tested.
> >
> > Nak (for now): [PATCH V3 2/2] NTB: Add support for flush request
> > interface
> >
> > Don't give up.  Please keep working on this, and the power management
> patch, to get them reviewed and accepted.  It's your choice whether or not
> to submit the patches, and when.  I'd encourage you to do it early, rather
> than delay.
> 
> I'd like to echo Allen's comment above.  Do not give up.  This code is very
> close to being accepted (once the issues that Allen and I pointed out are
> addressed).  If you can get us another version on/before Wednesday, it
> should make the 4.5 release (assuming it is acceptable and the wdinow is not
> closed prematurely).
> 
> Thanks for all of your hard work (and many thanks to Allen for his reviews of
> the code as well).

I'll change code right now and please help reviewed it again.