| Message ID | 20181026163659.21590-1-ajayg@nvidia.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add support for USB Type-C interface on latest NVIDIA GPU | expand |
On Fri, Oct 26, 2018 at 09:36:57AM -0700, Ajay Gupta wrote: > Hi Heikki and Wolfram, > > These two changes add support for USB Type-C interface on latest NVIDIA GPU card. > The Type-C controller used is Cypress CCGx and is over I2C interface. > > I2C host controller has known limitation of sending STOP after every read. Since > each read can be of 4 byte maximum length so there is a limit of 4 byte read. > This is mentioned in adapter quirks as "max_read_len = 4" > > I2C host controller is mainly used for "write-then-read" or "write" messages so added > the flag I2C_AQ_COMB_WRITE_THEN_READ in adapter quirks. > > PATCH[2/2] on ucsi driver now have added logic to check i2c adapter quirks and > issues i2c read transfer based on max_read_len quirk settings. This will make sure > the read limitation is not affecting I2C host which do not have such limitation. > > I think the patches should through usb tree because the main functionality is > usb Type-C. FWIW, Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > Thanks > Ajay > > Ajay Gupta (2): > i2c: buses: add i2c bus driver for NVIDIA GPU > usb: typec: ucsi: add support for Cypress CCGx > > Documentation/i2c/busses/i2c-nvidia-gpu | 18 ++ > MAINTAINERS | 7 + > drivers/i2c/busses/Kconfig | 9 + > drivers/i2c/busses/Makefile | 1 + > drivers/i2c/busses/i2c-nvidia-gpu.c | 368 ++++++++++++++++++++++++ > drivers/usb/typec/ucsi/Kconfig | 10 + > drivers/usb/typec/ucsi/Makefile | 2 + > drivers/usb/typec/ucsi/ucsi_ccg.c | 307 ++++++++++++++++++++ > 8 files changed, 722 insertions(+) > create mode 100644 Documentation/i2c/busses/i2c-nvidia-gpu > create mode 100644 drivers/i2c/busses/i2c-nvidia-gpu.c > create mode 100644 drivers/usb/typec/ucsi/ucsi_ccg.c > > -- > 2.17.1 >
Hi Wolfram, Do you have any comments on these patches? Thanks Ajay > nvpublic > -----Original Message----- > From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > Sent: Monday, October 29, 2018 5:43 AM > To: Ajay Gupta <ajayg@nvidia.com> > Cc: wsa@the-dreams.de; heikki.krogerus@linux.intel.com; peda@axentia.se; > linux-usb@vger.kernel.org; linux-i2c@vger.kernel.org > Subject: Re: [PATCH v15 0/2] Add support for USB Type-C interface on latest > NVIDIA GPU > > On Fri, Oct 26, 2018 at 09:36:57AM -0700, Ajay Gupta wrote: > > Hi Heikki and Wolfram, > > > > These two changes add support for USB Type-C interface on latest NVIDIA > GPU card. > > The Type-C controller used is Cypress CCGx and is over I2C interface. > > > > I2C host controller has known limitation of sending STOP after every > > read. Since each read can be of 4 byte maximum length so there is a limit of > 4 byte read. > > This is mentioned in adapter quirks as "max_read_len = 4" > > > > I2C host controller is mainly used for "write-then-read" or "write" > > messages so added the flag I2C_AQ_COMB_WRITE_THEN_READ in adapter > quirks. > > > > PATCH[2/2] on ucsi driver now have added logic to check i2c adapter > > quirks and issues i2c read transfer based on max_read_len quirk > > settings. This will make sure the read limitation is not affecting I2C host > which do not have such limitation. > > > > I think the patches should through usb tree because the main > > functionality is usb Type-C. > > FWIW, > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > > > > Thanks > > Ajay > > > > Ajay Gupta (2): > > i2c: buses: add i2c bus driver for NVIDIA GPU > > usb: typec: ucsi: add support for Cypress CCGx > > > > Documentation/i2c/busses/i2c-nvidia-gpu | 18 ++ > > MAINTAINERS | 7 + > > drivers/i2c/busses/Kconfig | 9 + > > drivers/i2c/busses/Makefile | 1 + > > drivers/i2c/busses/i2c-nvidia-gpu.c | 368 ++++++++++++++++++++++++ > > drivers/usb/typec/ucsi/Kconfig | 10 + > > drivers/usb/typec/ucsi/Makefile | 2 + > > drivers/usb/typec/ucsi/ucsi_ccg.c | 307 ++++++++++++++++++++ > > 8 files changed, 722 insertions(+) > > create mode 100644 Documentation/i2c/busses/i2c-nvidia-gpu > > create mode 100644 drivers/i2c/busses/i2c-nvidia-gpu.c > > create mode 100644 drivers/usb/typec/ucsi/ucsi_ccg.c > > > > -- > > 2.17.1 > > > > -- > With Best Regards, > Andy Shevchenko >
On Mon, Oct 29, 2018 at 02:42:37PM +0200, Andy Shevchenko wrote: > On Fri, Oct 26, 2018 at 09:36:57AM -0700, Ajay Gupta wrote: > > Hi Heikki and Wolfram, > > > > These two changes add support for USB Type-C interface on latest NVIDIA GPU card. > > The Type-C controller used is Cypress CCGx and is over I2C interface. > > > > I2C host controller has known limitation of sending STOP after every read. Since > > each read can be of 4 byte maximum length so there is a limit of 4 byte read. > > This is mentioned in adapter quirks as "max_read_len = 4" > > > > I2C host controller is mainly used for "write-then-read" or "write" messages so added > > the flag I2C_AQ_COMB_WRITE_THEN_READ in adapter quirks. > > > > PATCH[2/2] on ucsi driver now have added logic to check i2c adapter quirks and > > issues i2c read transfer based on max_read_len quirk settings. This will make sure > > the read limitation is not affecting I2C host which do not have such limitation. > > > > I think the patches should through usb tree because the main functionality is > > usb Type-C. > > FWIW, > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Thanks, Andy. Your review is worth something :) May I ask you to add your tag to the individual patches (as long as it is not a patch bomb), so patchwork will pick them up and I see them immediately?
On Fri, Nov 09, 2018 at 05:45:16PM +0100, Wolfram Sang wrote: > On Mon, Oct 29, 2018 at 02:42:37PM +0200, Andy Shevchenko wrote: > > On Fri, Oct 26, 2018 at 09:36:57AM -0700, Ajay Gupta wrote: > > > Hi Heikki and Wolfram, > > > > > > These two changes add support for USB Type-C interface on latest NVIDIA GPU card. > > > The Type-C controller used is Cypress CCGx and is over I2C interface. > > > > > > I2C host controller has known limitation of sending STOP after every read. Since > > > each read can be of 4 byte maximum length so there is a limit of 4 byte read. > > > This is mentioned in adapter quirks as "max_read_len = 4" > > > > > > I2C host controller is mainly used for "write-then-read" or "write" messages so added > > > the flag I2C_AQ_COMB_WRITE_THEN_READ in adapter quirks. > > > > > > PATCH[2/2] on ucsi driver now have added logic to check i2c adapter quirks and > > > issues i2c read transfer based on max_read_len quirk settings. This will make sure > > > the read limitation is not affecting I2C host which do not have such limitation. > > > > > > I think the patches should through usb tree because the main functionality is > > > usb Type-C. > > > > FWIW, > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > Thanks, Andy. Your review is worth something :) > > May I ask you to add your tag to the individual patches (as long as it > is not a patch bomb), so patchwork will pick them up and I see them > immediately? Hmm... It would be a bit difficult (requires to download patches again as mbox). I would rather give you a hint how I resolve such problem when apply a tag to a pile of patches. Pre-requisites: - git branch with all patches in question located at the top (let's assume 2 patches) You may just run the following: git filter-branch --msg-filter \ 'sed -e "/Signed-off-by:/ a Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>"' \ -f HEAD~2..HEAD It will append a given line after first match with SoB one (`man sed` for details). Check without -f (which enforces to rewrite) first.
> Hmm... It would be a bit difficult (requires to download patches again as mbox). > I would rather give you a hint how I resolve such problem when apply a tag to a > pile of patches. I don't mean now, for future patch series, that is... With this one, all is fine... > git filter-branch --msg-filter \ > 'sed -e "/Signed-off-by:/ a Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>"' \ > -f HEAD~2..HEAD Yes, I have something in place like this, no problem. The issue is that patches which have a review indicated (by patchwork's patch list) get a priority boost when I process patches. Maybe patchwork will learn someday to handle tags given to coverletters... I am probably not the first one to stumble over this.