> create mode 100644 Documentation/i2c/busses/i2c-nvidia-gpu
> > create mode 100644 drivers/i2c/busses/i2c-nvidia-gpu.c
> >
> > diff --git a/Documentation/i2c/busses/i2c-nvidia-gpu
> > b/Documentation/i2c/busses/i2c-nvidia-gpu
> > new file mode 1006
Hi Peter,
> > Signed-off-by: Ajay Gupta
> > Reviewed-by: Andy Shevchenko
> > Reviewed-by: Heikki Krogerus
> > ---
> > Changes from v1 -> v2
> > None
> > Changes from v2 -> v3
> > Fixed review comments from Andy and Thierry
> >
Hi Peter,
> -Original Message-
> From: Peter Rosin
> Sent: Friday, September 7, 2018 2:13 AM
> To: Ajay Gupta ; w...@the-dreams.de;
> heikki.kroge...@linux.intel.com
> Cc: linux-usb@vger.kernel.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH v9 2/2] usb: typec:
r, &gpu_ccgx_ucsi);
> >>> + if (!i2cd->client) {
> >>> + dev_err(i2cd->dev, "i2c_new_device failed\n");
> >>> + return -ENODEV;
> >>> + }
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static int gpu_i2c_probe(struct pci_dev *pdev, const struct
> >>> +pci_device_id *id) {
> >>> + struct gpu_i2c_dev *i2cd;
> >>> + int status;
> >>> +
> >>> + i2cd = devm_kzalloc(&pdev->dev, sizeof(struct gpu_i2c_dev),
> >> GFP_KERNEL);
> >>> + if (!i2cd)
> >>> + return -ENOMEM;
> >>> +
> >>> + i2cd->dev = &pdev->dev;
> >>> + dev_set_drvdata(&pdev->dev, i2cd);
> >>> +
> >>> + status = pcim_enable_device(pdev);
> >>> + if (status < 0) {
> >>> + dev_err(&pdev->dev, "pcim_enable_device failed %d\n",
> >> status);
> >>> + return status;
> >>> + }
> >>> +
> >>> + pci_set_master(pdev);
> >>> +
> >>> + i2cd->regs = pcim_iomap(pdev, 0, 0);
> >>> + if (!i2cd->regs) {
> >>> + dev_err(&pdev->dev, "pcim_iomap failed\n");
> >>> + return -ENOMEM;
> >>> + }
> >>> +
> >>> + status = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_MSI);
> >>> + if (status < 0) {
> >>> + dev_err(&pdev->dev, "pci_alloc_irq_vectors err %d\n",
> >> status);
> >>> + return status;
> >>> + }
> >>> +
> >>> + mutex_init(&i2cd->mutex);
> >>> + gpu_enable_i2c_bus(i2cd);
> >>> +
> >>> + i2c_set_adapdata(&i2cd->adapter, i2cd);
> >>> + i2cd->adapter.owner = THIS_MODULE;
> >>> + strlcpy(i2cd->adapter.name, "NVIDIA GPU I2C adapter",
> >>> + sizeof(i2cd->adapter.name));
> >>> + i2cd->adapter.algo = &gpu_i2c_algorithm;
> >>> + i2cd->adapter.quirks = &gpu_i2c_quirks;
> >>> + i2cd->adapter.dev.parent = &pdev->dev;
> >>> + status = i2c_add_adapter(&i2cd->adapter);
> >>> + if (status < 0)
> >>> + goto free_irq_vectors;
> >>> +
> >>> + status = gpu_populate_client(i2cd, pdev->irq);
> >>> + if (status < 0) {
> >>> + dev_err(&pdev->dev, "gpu_populate_client failed %d\n",
> >> status);
> >>> + goto del_adapter;
> >>> + }
> >>> +
> >>> + return 0;
> >>> +
> >>> +del_adapter:
> >>> + i2c_del_adapter(&i2cd->adapter);
> >>> +free_irq_vectors:
> >>> + pci_free_irq_vectors(pdev);
> >>> + return status;
> >>> +}
> >>> +
> >>> +static void gpu_i2c_remove(struct pci_dev *pdev) {
> >>> + struct gpu_i2c_dev *i2cd = dev_get_drvdata(&pdev->dev);
> >>> +
> >>> + i2c_del_adapter(&i2cd->adapter);
> >>> + pci_free_irq_vectors(pdev);
> >>> +}
> >>> +
> >>> +static int gpu_i2c_resume(struct device *dev) {
> >>> + struct gpu_i2c_dev *i2cd = dev_get_drvdata(dev);
> >>> +
> >>> + gpu_enable_i2c_bus(i2cd);
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static int gpu_i2c_idle(struct device *dev) {
> >>> + struct gpu_i2c_dev *i2cd = dev_get_drvdata(dev);
> >>> +
> >>> + if (!mutex_trylock(&i2cd->mutex)) {
> >>> + dev_info(dev, "-EBUSY\n");
> >>> + return -EBUSY;
> >>> + }
> >>> + mutex_unlock(&i2cd->mutex);
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>> +UNIVERSAL_DEV_PM_OPS(gpu_i2c_driver_pm, NULL, gpu_i2c_resume,
> >>> +gpu_i2c_idle);
> >>> +
> >>> +static struct pci_driver gpu_i2c_driver = {
> >>> + .name = "nvidia-gpu",
> >>> + .id_table = gpu_i2c_ids,
> >>> + .probe = gpu_i2c_probe,
> >>> + .remove = gpu_i2c_remove,
> >>> + .driver = {
> >>> + .pm = &gpu_i2c_driver_pm,
> >>> + },
> >>> +};
> >>> +
> >>> +module_pci_driver(gpu_i2c_driver);
> >>> +
> >>> +MODULE_AUTHOR("Ajay Gupta ");
> >>> +MODULE_DESCRIPTION("Nvidia GPU I2C controller Driver");
> >>> +MODULE_LICENSE("GPL v2");
> >>>
> >
Hi Peter,
> >>> + memcpy(buf1, ((const void *)uc->ppm.data) + 0x20, sizeof(buf1));
> >>> + memcpy(buf2, ((const void *)uc->ppm.data) + 0x8, sizeof(buf2));
> >>> +
> >>> + status = ccg_write(uc, *(u16 *)buf, buf1, sizeof(buf1));
> >>
> >> This seems to be endian-dependent. May I suggest that you do
Latest NVIDIA GPU cards have a Cypress CCGx Type-C controller
over I2C interface.
This UCSI I2C driver uses I2C bus driver interface for communicating
with Type-C controller.
Signed-off-by: Ajay Gupta
Reviewed-by: Andy Shevchenko
Acked-by: Heikki Krogerus
---
Changes from v1 ->
Latest NVIDIA GPU card has USB Type-C interface. There is a
Type-C controller which can be accessed over I2C.
This driver adds I2C bus driver to communicate with Type-C controller.
I2C client driver will be part of USB Type-C UCSI driver.
Signed-off-by: Ajay Gupta
Reviewed-by: Andy Shevchenko
Hi Peter,
.
>SMBUS has nothing to do with the >problem, that was just an example. An I2C
>>client driver can issue such I2C xfers all by >itself without going through
>emulation, so >just dropping the _EMUL flag is not the >answer. And I'd be
>surprised if the >hardware doesn't support s
Hi Peter,
> >> +
> >> + if (msgs[i].flags & I2C_M_RD) {
> >> + /* gpu_i2c_read has implicit start and stop */
> >> + status = gpu_i2c_read(i2cd, msgs[i].buf, msgs[i].len);
> >> + if (status < 0)
> >> + return stat
Hi Peter,
> > +
> > + if (msgs[i].flags & I2C_M_RD) {
> > + /* gpu_i2c_read has implicit start and stop */
> > + status = gpu_i2c_read(i2cd, msgs[i].buf,
> > msgs[i].len);
> > + if (status < 0)
Hi Peter,
> > Latest NVIDIA GPU cards have a Cypress CCGx Type-C controller over I2C
> > interface.
> >
> > This UCSI I2C driver uses I2C bus driver interface for communicating
> > with Type-C controller.
> >
> > Signed-off-by: Ajay Gupta
> > Re
notice
> >> that before, but that means that all the new offsets and sizes
> >> defined in v10 are available with
> >> offsetof() and sizeof() which would be much neater than a bunch of defines.
> >> Sorry for not catching this earlier!
> >>
> >> See below for an example.
> > Sure.
> >>
> >>> +
> >>> + uc->ppm.cmd = ucsi_ccg_cmd;
> >>> + uc->ppm.sync = ucsi_ccg_sync;
> >>> + uc->dev = dev;
> >>> + uc->client = client;
> >>> +
> >>> + /* reset ccg device and initialize ucsi */
> >>> + status = ucsi_ccg_init(uc);
> >>> + if (status < 0) {
> >>> + dev_err(uc->dev, "ucsi_ccg_init failed - %d\n", status);
> >>> + return status;
> >>> + }
> >>> +
> >>> + uc->irq = client->irq;
> >>> +
> >>> + status = devm_request_threaded_irq(dev, uc->irq, NULL,
> >> ccg_irq_handler,
> >>> +IRQF_ONESHOT |
> >> IRQF_TRIGGER_HIGH,
> >>> +dev_name(dev), uc);
> >>> + if (status < 0) {
> >>> + dev_err(uc->dev, "request_threaded_irq failed - %d\n",
> >> status);
> >>> + return status;
> >>> + }
> >>> +
> >>> + uc->ucsi = ucsi_register_ppm(dev, &uc->ppm);
> >>> + if (IS_ERR(uc->ucsi)) {
> >>> + dev_err(uc->dev, "ucsi_register_ppm failed\n");
> >>> + return PTR_ERR(uc->ucsi);
> >>> + }
> >>> +
> >>> + rab = CCGX_I2C_RAB_UCSI_DATA_BLOCK(USBC_VERSION_OFFSET);
> >>> + status = ccg_read(uc, rab, (u8 *)(uc->ppm.data) +
> >> USBC_VERSION_OFFSET,
> >>> + USBC_VERSION_SIZE);
> >>
> >> E.g.
> >>rab = CCGX_I2C_RAB_UCSI_DATA_BLOCK(offsetof(struct ucsi_data,
> >> version));
> >>status = ccg_read(uc, rab, (u8 *)&uc->ppm.data->version,
> >> sizeof(uc->ppm.data->version));
> >>
> >> Hmm, but this highlights that you are not doing any endian conversion
> >> of the fields in that struct as you read/write it.
> >
> >> Do you need to in case you have an endian mismatch?
> > Looks like don't need it. I have tested it and it works as is.
>
> Yeah, but have you tested the driver on a machine with the other byte-sex?
No, I think better to convert to desired endian.
Thanks
Ajay
--
nvpublic
--
> Cheers,
> Peter
>
> > Thanks
> > Ajay
> >
> > --
> > nvpublic
> > --
> >>
> >> Cheers,
> >> Peter
> >>
> >>> + if (status < 0) {
> >>> + ucsi_unregister_ppm(uc->ucsi);
> >>> + return status;
> >>> + }
> >>> +
> >>> + i2c_set_clientdata(client, uc);
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static int ucsi_ccg_remove(struct i2c_client *client) {
> >>> + struct ucsi_ccg *uc = i2c_get_clientdata(client);
> >>> +
> >>> + ucsi_unregister_ppm(uc->ucsi);
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static const struct i2c_device_id ucsi_ccg_device_id[] = {
> >>> + {"ccgx-ucsi", 0},
> >>> + {}
> >>> +};
> >>> +MODULE_DEVICE_TABLE(i2c, ucsi_ccg_device_id);
> >>> +
> >>> +static struct i2c_driver ucsi_ccg_driver = {
> >>> + .driver = {
> >>> + .name = "ucsi_ccg",
> >>> + },
> >>> + .probe = ucsi_ccg_probe,
> >>> + .remove = ucsi_ccg_remove,
> >>> + .id_table = ucsi_ccg_device_id,
> >>> +};
> >>> +
> >>> +module_i2c_driver(ucsi_ccg_driver);
> >>> +
> >>> +MODULE_AUTHOR("Ajay Gupta ");
> >>> +MODULE_DESCRIPTION("UCSI driver for Cypress CCGx Type-C
> >>> +controller"); MODULE_LICENSE("GPL v2");
> >>>
> >
Hi Peter,
> >>> + if (msgs[i].flags & I2C_M_RD) {
> >>> + /* gpu_i2c_read has implicit start and stop */
> >>> + status = gpu_i2c_read(i2cd, msgs[i].buf,
> msgs[i].len);
> >>> + if (status < 0)
> >>> +
Hi Peter
> > +static int ucsi_ccg_send_data(struct ucsi_ccg *uc) {
> > + unsigned char buf1[USBC_MSG_OUT_SIZE];
> > + unsigned char buf2[USBC_CONTROL_SIZE];
> > + int status;
> > + u16 rab;
> > +
> > + memcpy(buf1, (u8 *)(uc->ppm.data) + US
Hi Peter
> > + if (msgs[i].flags & I2C_M_RD) {
> > + /* gpu_i2c_read has implicit start and stop */
> > + status = gpu_i2c_read(i2cd, msgs[i].buf,
> >> msgs[i].len);
> > + if (status < 0)
> > +
Hi Peter
> > > +static int ucsi_ccg_send_data(struct ucsi_ccg *uc) {
> > > + unsigned char buf1[USBC_MSG_OUT_SIZE];
> > > + unsigned char buf2[USBC_CONTROL_SIZE];
> > > + int status;
> > > + u16 rab;
> > > +
> > > + memcpy(buf1, (u8 *)(uc->ppm.data)
Latest NVIDIA GPU card has USB Type-C interface. There is a
Type-C controller which can be accessed over I2C.
This driver adds I2C bus driver to communicate with Type-C controller.
I2C client driver will be part of USB Type-C UCSI driver.
Signed-off-by: Ajay Gupta
Reviewed-by: Andy Shevchenko
Latest NVIDIA GPU cards have a Cypress CCGx Type-C controller
over I2C interface.
This UCSI I2C driver uses I2C bus driver interface for communicating
with Type-C controller.
Signed-off-by: Ajay Gupta
Reviewed-by: Andy Shevchenko
Acked-by: Heikki Krogerus
---
Changes from v1 ->
sses/i2c-nvidia-gpu
> > create mode 100644 drivers/i2c/busses/i2c-nvidia-gpu.c
> >
> > diff --git a/Documentation/i2c/busses/i2c-nvidia-gpu
> > b/Documentation/i2c/busses/i2c-nvidia-gpu
> > new file mode 100644
> > index 000..31884d2
> > --- /dev/null
>
Hi Peter,
> +static int ucsi_ccg_send_data(struct ucsi_ccg *uc) {
> +unsigned char buf1[USBC_MSG_OUT_SIZE];
> +unsigned char buf2[USBC_CONTROL_SIZE];
> +int status;
> +u16 rab;
> +
> +memcpy(buf1, (u8 *)(uc->ppm.dat
Hi Peter,
> -Original Message-
> From: linux-i2c-ow...@vger.kernel.org
> On Behalf Of Peter Rosin
> Sent: Tuesday, September 11, 2018 1:55 AM
> To: Ajay Gupta ; w...@the-dreams.de;
> heikki.kroge...@linux.intel.com
> Cc: linux-usb@vger.kernel.org; linux-...@vger.ker
Latest NVIDIA GPU card has USB Type-C interface. There is a
Type-C controller which can be accessed over I2C.
This driver adds I2C bus driver to communicate with Type-C controller.
I2C client driver will be part of USB Type-C UCSI driver.
Signed-off-by: Ajay Gupta
Reviewed-by: Andy Shevchenko
Latest NVIDIA GPU cards have a Cypress CCGx Type-C controller
over I2C interface.
This UCSI I2C driver uses I2C bus driver interface for communicating
with Type-C controller.
Signed-off-by: Ajay Gupta
Reviewed-by: Andy Shevchenko
Acked-by: Heikki Krogerus
---
Changes from v1 ->
gt; drivers/i2c/busses/i2c-nvidia-gpu.c | 368
>
> > 5 files changed, 403 insertions(+)
> > create mode 100644 Documentation/i2c/busses/i2c-nvidia-gpu
> > create mode 100644 drivers/i2c/busses/i2c-nvidia-gpu.c
> >
>
Hi Peter,
> > This driver adds I2C bus driver to communicate with Type-C controller.
> > I2C client driver will be part of USB Type-C UCSI driver.
> >
> > Signed-off-by: Ajay Gupta
> > Reviewed-by: Andy Shevchenko
> > Reviewed-by: Heikki Krogerus
> >
Hi Peter,
> >>> This driver adds I2C bus driver to communicate with Type-C controller.
> >>> I2C client driver will be part of USB Type-C UCSI driver.
> >>>
> >>> Signed-off-by: Ajay Gupta
> >>> Reviewed-by: Andy Shevchenko
> &g
Hi Heikki and Peter,
> > > Can we get the working set in while the issues is being debugged?
> >
> > I'm not the one making the decision, and I don't even know if this is
> > going through the i2c or the usb tree? If it's going through the i2c
> > tree you need a tag from the usb people (Greg?) on
Hi Heikki and Peter,
> > > > Can we get the working set in while the issues is being debugged?
> > >
> > > I'm not the one making the decision, and I don't even know if this
> > > is going through the i2c or the usb tree? If it's going through the
> > > i2c tree you need a tag from the usb people
Hi Peter,
> I'm not the one making the decision, and I don't even know if this
> is going through the i2c or the usb tree? If it's going through the
> i2c tree you need a tag from the usb people (Greg?) on patch 2/2,
> and if it's going through the usb tree, you need a tag from
Hi Wolfram,
> > > > > > Can we get the working set in while the issues is being debugged?
> > > > >
> > > > > I'm not the one making the decision, and I don't even know if
> > > > > this is going through the i2c or the usb tree? If it's going
> > > > > through the i2c tree you need a tag from the
Hi Wolfram,
> > > > We got confirmation from HW team about 4 byte read limitation.
> > > > There has to be a STOP after every single read cycle. One read
> > > > cycle supports maximum of
> > > > 4 byte burst. I will update the patches with a comment on this.
> > >
> > > Could it be that this is m
d through usb tree because the main functionality is
usb Type-C.
The changes have been reviewed by Andy Shevchenko and Heikki Krogerus.
Peter Rosin also helped review the patches and provided valuable comments.
Thanks to all reviewers.
Thanks
Ajay
Ajay Gupta (2):
i2c: buses: add i2c bus driver for
Latest NVIDIA GPU cards have a Cypress CCGx Type-C controller
over I2C interface.
This UCSI I2C driver uses I2C bus driver interface for communicating
with Type-C controller.
Signed-off-by: Ajay Gupta
Reviewed-by: Andy Shevchenko
Acked-by: Heikki Krogerus
---
Changes from v1 ->
Latest NVIDIA GPU card has USB Type-C interface. There is a
Type-C controller which can be accessed over I2C.
This driver adds I2C bus driver to communicate with Type-C controller.
I2C client driver will be part of USB Type-C UCSI driver.
Signed-off-by: Ajay Gupta
Reviewed-by: Andy Shevchenko
Heikki Krogerus.
> Peter Rosin also helped review the patches and provided valuable comments.
> Thanks to all reviewers.
>
> Thanks
> Ajay
>
> Ajay Gupta (2):
> i2c: buses: add i2c bus driver for NVIDIA GPU
> usb: typec: ucsi: add support for Cypress CCGx
>
>
Hi Heikki,
> I still have a few more comments below..
Thanks for reviewing.
> On Wed, Oct 03, 2018 at 11:27:28AM -0700, Ajay Gupta wrote:
> > Latest NVIDIA GPU cards have a Cypress CCGx Type-C controller over I2C
> > interface.
> >
> > This UCSI I2C driver use
Hi Andy
> > > > Latest NVIDIA GPU cards have a Cypress CCGx Type-C controller over
> > > > I2C interface.
> > > >
> > > > This UCSI I2C driver uses I2C bus driver interface for
> > > > communicating with Type-C controller.
>
> > > > + /*
> > > > +* Flush CCGx RESPONSE queue by ackin
Hi Wolfram,
> > I don't think SMBus is an option in this case since the intended
> > client (Cypress something in patch 2/2) does xfers that would need
> > 16-bit commands and I think they are always 8-bit in SMBus, no?
>
> Yes. Command is 8 bit, data can be 16. Thanks for the heads up!
Please hel
Hi Andy,
> > > > > > Latest NVIDIA GPU cards have a Cypress CCGx Type-C controller
> > > > > > over I2C interface.
> > > > > >
> > > > > > This UCSI I2C driver uses I2C bus driver interface for
> > > > > > communicating with Type-C controller.
> > >
> > > > > > + /*
> > > > > > +* Flush CCGx
Hi Heikki,
> > > I still didn't understand why can't this just be taken care of in
> > > your I2C host driver? Why can't you just read 4 bytes at a time in
> > > your master_xfer hook until you have received as much as the message
> > > is asking, and only after that return?
> >
> > The I2C host ha
IRQF_ONESHOT |
> > > IRQF_TRIGGER_HIGH,
> > > > + dev_name(dev), uc);
> > > > + if (status < 0) {
> > > > + dev_err(uc->dev, "request_threaded_irq fai
Hi Peter and Andy,
> Shouldn't you return -ETIMEDOUT if count == 0?
> >>> Yes. Good catch. Does the below fix looks ok?
> >>>
> >>> do {
> >>> status = ccg_write(uc, CCGX_RAB_INTR_REG, &data,
> sizeof(data));
> >>> if (status < 0)
> >>>
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
Latest NVIDIA GPU card has USB Type-C interface. There is a
Type-C controller which can be accessed over I2C.
This driver adds I2C bus driver to communicate with Type-C controller.
I2C client driver will be part of USB Type-C UCSI driver.
Signed-off-by: Ajay Gupta
---
Changes from v1 ->
Latest NVIDIA GPU cards have a Cypress CCGx Type-C controller
over I2C interface.
This UCSI I2C driver uses I2C bus driver interface for communicating
with Type-C controller.
Signed-off-by: Ajay Gupta
---
Changes from v1 -> v2
Fixed identation in drivers/usb/typec/ucsi/Kconfig
Chan
Hi Wolfram,
Do you have any comments on these patches?
Thanks
Ajay
> nvpublic
> -Original Message-
> From: Andy Shevchenko
> Sent: Monday, October 29, 2018 5:43 AM
> To: Ajay Gupta
> Cc: w...@the-dreams.de; heikki.kroge...@linux.intel.com; p...@axentia.se;
> linu
Hi Wolfram,
> > Latest NVIDIA GPU card has USB Type-C interface. There is a Type-C
> > controller which can be accessed over I2C.
> >
> > This driver adds I2C bus driver to communicate with Type-C controller.
> > I2C client driver will be part of USB Type-C UCSI drive
Hi Wolfram,
> > It will be good if both of them can go together either through I2C or
> > USB subsystem. Since USB part is reviewed and has Acked-by Heikki so
> > please take that also.
>
> Hmmm, technicallly, there is no need to let them go together. There is no
> strict dependency.
Agree.
> Yet
Hi Wolfram,
> > @@ -140,5 +140,6 @@ obj-$(CONFIG_I2C_SIBYTE)+= i2c-sibyte.o
> > obj-$(CONFIG_I2C_XGENE_SLIMPRO) += i2c-xgene-slimpro.o
> > obj-$(CONFIG_SCx200_ACB) += scx200_acb.o
> > obj-$(CONFIG_I2C_FSI) += i2c-fsi.o
> > +obj-$(CONFIG_I2C_NVIDIA_GPU) += i2c-nvidia
Used to send command to ccg controller
Signed-off-by: Ajay Gupta
---
drivers/usb/typec/ucsi/ucsi_ccg.c | 252 --
1 file changed, 243 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/typec/ucsi/ucsi_ccg.c
b/drivers/usb/typec/ucsi/ucsi_ccg.c
index 4d35279ab853
Adding support for commands which will be used for firmware
flashing.
Signed-off-by: Ajay Gupta
---
drivers/usb/typec/ucsi/ucsi_ccg.c | 216 ++
1 file changed, 216 insertions(+)
diff --git a/drivers/usb/typec/ucsi/ucsi_ccg.c
b/drivers/usb/typec/ucsi/ucsi_ccg.c
Read PD port number information and save.
Signed-off-by: Ajay Gupta
---
drivers/usb/typec/ucsi/ucsi_ccg.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/typec/ucsi/ucsi_ccg.c
b/drivers/usb/typec/ucsi/ucsi_ccg.c
index dce9126b6a37..b30ca51120a3 100644
--- a/drivers/usb
Hi Heikki
This patch set adds support for updating firmware on Cypress CCGx controller.
I have tested them on NVIDIA GPU card.
I will be posting firmware binary patch to linux-firmware.git repo soon.
Please help review this set.
Thanks
Ajay
Ajay Gupta (7):
usb: typec: ucsi: add get_fw_info
Function is to get the details of ccg firmware and device version.
Signed-off-by: Ajay Gupta
---
drivers/usb/typec/ucsi/ucsi_ccg.c | 76 ++-
1 file changed, 74 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/typec/ucsi/ucsi_ccg.c
b/drivers/usb/typec/ucsi
This will be needed to check if latest fw is already flashed.
Signed-off-by: Ajay Gupta
---
drivers/usb/typec/ucsi/ucsi_ccg.c | 139 ++
1 file changed, 139 insertions(+)
diff --git a/drivers/usb/typec/ucsi/ucsi_ccg.c
b/drivers/usb/typec/ucsi/ucsi_ccg.c
index
Added check to see the currently flashed or new firmware being
flashed is from a supported vendor.
Signed-off-by: Ajay Gupta
---
drivers/usb/typec/ucsi/ucsi_ccg.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/usb/typec/ucsi/ucsi_ccg.c
b/drivers/usb
-off-by: Ajay Gupta
---
drivers/usb/typec/ucsi/ucsi_ccg.c | 283 ++
1 file changed, 283 insertions(+)
diff --git a/drivers/usb/typec/ucsi/ucsi_ccg.c
b/drivers/usb/typec/ucsi/ucsi_ccg.c
index 1aa6ede764b5..da83c145a392 100644
--- a/drivers/usb/typec/ucsi/ucsi_ccg.c
+++ b
Hi Greg
> -Original Message-
> From: Greg KH
> Sent: Thursday, January 17, 2019 11:06 PM
> To: Ajay Gupta
> Cc: heikki.kroge...@linux.intel.com; linux-usb@vger.kernel.org
> Subject: Re: [PATCH 1/7] usb: typec: ucsi: add get_fw_info function
>
> On Thu, Jan 17,
Hi Heikki,
> > Function is to get the details of ccg firmware and device version.
> >
> > Signed-off-by: Ajay Gupta
> > ---
> > drivers/usb/typec/ucsi/ucsi_ccg.c | 76
> > ++-
> > 1 file changed, 74 insertions(+), 2 deletions
Hi Greg
-off-by: Ajay Gupta
> > ---
> > drivers/usb/typec/ucsi/ucsi_ccg.c | 139
> > ++
> > 1 file changed, 139 insertions(+)
> >
> > diff --git a/drivers/usb/typec/ucsi/ucsi_ccg.c
> > b/drivers/usb/typec/ucsi/ucsi_ccg.c
&
Hi Greg,
> On Thu, Jan 17, 2019 at 05:12:38PM -0800, Ajay Gupta wrote:
> > This will be needed to check if latest fw is already flashed.
>
> Very odd changelog text, please make this more detailed.
Sure.
> And your email threading broke here, did your email client change?
Th
Hi Heikki,
> > Signed-off-by: Ajay Gupta
> > ---
> > drivers/usb/typec/ucsi/ucsi_ccg.c | 139
> > ++
> > 1 file changed, 139 insertions(+)
> >
> > diff --git a/drivers/usb/typec/ucsi/ucsi_ccg.c
> > b/drivers/
Hi Greg,
> On Thu, Jan 17, 2019 at 05:09:04PM -0800, Ajay Gupta wrote:
> > Used to send command to ccg controller
>
> Writing changelog comments is hard, but please do more than just tiny snippets
> like this. Explain _why_ this change is needed in detail please.
>
&g
Hi Heikki,
> From: Heikki Krogerus
> Sent: Friday, January 18, 2019 7:30 AM
> To: Ajay Gupta
> Cc: linux-usb@vger.kernel.org
> Subject: Re: [PATCH 6/7] usb: typec: ucsi: add check for supported vendor
>
> On Thu, Jan 17, 2019 at 05:13:02PM -0800, Ajay Gupta wrote:
>
Hi Heikki
> > Used to send command to ccg controller
> >
> > Signed-off-by: Ajay Gupta
> > ---
> > drivers/usb/typec/ucsi/ucsi_ccg.c | 252
> > --
> > 1 file changed, 243 insertions(+), 9 deletions(-)
> >
> >
Hi Heikki
> > > > Used to send command to ccg controller
> > > >
> > > > Signed-off-by: Ajay Gupta
> > > > ---
> > > > drivers/usb/typec/ucsi/ucsi_ccg.c | 252
> > > > --
> > > > 1
Ajay Gupta (6):
usb: typec: ucsi: add get_fw_info function
usb: typec: ucsi: add ccg command framework
usb: typec: ucsi: add port num info
usb: typec: ucsi: add cmd used for fw flashing
usb: typec: ucsi: add fw update needed check
usb: typec: ucsi: add firmware flashing support
drivers
Read PD port number information and save. It will be
required while sending PD_PORT_ENABLE command.
Signed-off-by: Ajay Gupta
---
Changes from v1:
- Updated commit message
- Used mask and shift instead of bitfield
drivers/usb/typec/ucsi/ucsi_ccg.c | 7 +++
1 file changed, 7
.
Signed-off-by: Ajay Gupta
---
Changes from v1:
- Updated commit message
- Used mask and shift instead of bit fields
drivers/usb/typec/ucsi/ucsi_ccg.c | 216 ++
1 file changed, 216 insertions(+)
diff --git a/drivers/usb/typec/ucsi/ucsi_ccg.c
b/drivers
-off-by: Ajay Gupta
---
Changes from v1:
- Updated commit message
- Dropped a few dev_dbg prints
drivers/usb/typec/ucsi/ucsi_ccg.c | 284 ++
1 file changed, 284 insertions(+)
diff --git a/drivers/usb/typec/ucsi/ucsi_ccg.c
b/drivers/usb/typec/ucsi
Used to send various commands to ccg controller. They are
mainly used during firmware update process.
We wait for response after sending the command and then
read the response from RAB_RESPONSE register.
Signed-off-by: Ajay Gupta
---
Changes from v1:
- Updated commit message and dropped
Function is to get the details of ccg firmware and device version.
It will be useful in debugging and also during firmware update.
Signed-off-by: Ajay Gupta
---
Changes from v1:
- Updated commit message
- Dropped uses of bitfield
- Removed dev_dbg prints
drivers/usb
Here we read the currently flashed firmware version of both
primary and secondary firmware and then compare it with
version of firmware file to determine if flashing is required.
Signed-off-by: Ajay Gupta
---
Changes from v1:
- Updated commit message
- Squashed patch 6/7 of v1
Hi Greg,
> On Mon, Jan 28, 2019 at 12:37:26PM -0800, Ajay Gupta wrote:
> > Function is to get the details of ccg firmware and device version.
> > It will be useful in debugging and also during firmware update.
> >
> > Signed-off-by: Ajay Gupta
> > ---
>
Hi Greg
> Subject: Re: [PATCH v2 1/6] usb: typec: ucsi: add get_fw_info function
>
> On Mon, Jan 28, 2019 at 12:37:26PM -0800, Ajay Gupta wrote:
> > Function is to get the details of ccg firmware and device version.
> > It will be useful in debugging and also d
Hi Greg
> On Mon, Jan 28, 2019 at 12:37:31PM -0800, Ajay Gupta wrote:
> > +
> /*
>
> > +* CCG firmware image (.cyacd) file line format
> > +*
> > +* :00[dd]cc/r/n
&
Hi Greg,
> On Mon, Jan 28, 2019 at 12:37:31PM -0800, Ajay Gupta wrote:
> > +static int ccg_restart(struct ucsi_ccg *uc)
> > +{
> > + struct device *dev = uc->dev;
> > + int status;
> > +
> > + status = ucsi_ccg_init(uc);
> > + if (status <
Hi Heikki,
> > Used to send various commands to ccg controller. They are mainly used
> > during firmware update process.
> >
> > We wait for response after sending the command and then read the
> > response from RAB_RESPONSE register.
> >
> > Signed-off-b
Hi Heikki,
> On Mon, Jan 28, 2019 at 12:37:28PM -0800, Ajay Gupta wrote:
> > Read PD port number information and save. It will be required while
> > sending PD_PORT_ENABLE command.
> >
> > Signed-off-by: Ajay Gupta
> > ---
> > Changes from v1:
> >
From: Ajay Gupta
Read PD port number information and save. It will be
required while sending PD_PORT_ENABLE command.
Signed-off-by: Ajay Gupta
---
Changes from v2 to v3
- Fixed comments from Heikki on removing SHIFT
drivers/usb/typec/ucsi/ucsi_ccg.c | 6 ++
1 file changed, 6
From: Ajay Gupta
Function is to get the details of ccg firmware and device version.
It will be useful in debugging and also during firmware update.
Signed-off-by: Ajay Gupta
---
Changes from v2 to v3
- Fixed comments from Greg on using __le16 and __packed
- Added enum_fw_mode
From: Ajay Gupta
Used to send various commands to ccg controller. They are
mainly used during firmware update process.
We wait for response after sending the command and then
read the response from RAB_RESPONSE register.
Signed-off-by: Ajay Gupta
---
Changes from v2 to v3
- Removed
Ajay Gupta (6):
usb: typec: ucsi: add get_fw_info function
usb: typec: ucsi: add ccg command framework
usb: typec: ucsi: add port num info
usb: typec: ucsi: add cmd used for fw flashing
usb: typec: ucsi: add fw update needed check
usb: typec: ucsi: add firmware flashing support
drivers
From: Ajay Gupta
Adding support for below commands which will be used
during firmware flashing.
- ENTER_FLASHING
- RESET
- PDPORT_ENABLE
- JUMP_TO_BOOT
- FLASH_ROW_RW
- VALIDATE_FW
I command specific mutex lock is also added to sync
between driver
From: Ajay Gupta
CCGx has two copies of the firmware in addition to the bootloader.
If the device is running FW1, FW2 can be updated with the new version.
Dual firmware mode allows the CCG device to stay in a PD contract and
support USB PD and Type-C functionality while a firmware update is in
From: Ajay Gupta
Here we read the currently flashed firmware version of both
primary and secondary firmware and then compare it with
version of firmware file to determine if flashing is required.
Signed-off-by: Ajay Gupta
---
Changes from v2 to v3
- Moved enum_fw_mode enum to patch [1
Hi Heikki
> -Original Message-
> From: linux-usb-ow...@vger.kernel.org On
> Behalf Of Heikki Krogerus
> Sent: Friday, February 1, 2019 2:48 AM
> To: Greg Kroah-Hartman ; Ajay Gupta
> ; Michael Hsu
> Cc: linux-usb@vger.kernel.org
> Subject: [PATCH 4/5] usb:
Hi Heikki,
> -Original Message-
> From: linux-usb-ow...@vger.kernel.org On
> Behalf Of Heikki Krogerus
> Sent: Friday, February 1, 2019 2:48 AM
> To: Greg Kroah-Hartman ; Ajay Gupta
> ; Michael Hsu
> Cc: linux-usb@vger.kernel.org
> Subject: [PATCH 5/5] usb:
Hi Heikki,
> -Original Message-
> From: linux-usb-ow...@vger.kernel.org On
> Behalf Of Heikki Krogerus
> Sent: Friday, February 1, 2019 2:48 AM
> To: Greg Kroah-Hartman ; Ajay Gupta
> ; Michael Hsu
> Cc: linux-usb@vger.kernel.org
> Subject: [PATCH 5/5] usb:
Hi Heikki,
> -Original Message-
> From: Heikki Krogerus
> Sent: Wednesday, February 6, 2019 4:12 AM
> To: Ajay Gupta
> Cc: linux-usb@vger.kernel.org; Ajay Gupta
> Subject: Re: [PATCH v3 0/6] Add support for firmware update on Cypres CCGx
>
> Hi Ajay,
>
>
itory at:
https://github.com/ajaykuee/linux-firmware.git
for you to fetch changes up to 2c139fe800f56c73c3e60932eb8cdbf1a7c2e1de:
nvidia: add TU10x typec controller firmware (2019-02-06 12:07:22 -0800)
--------
Ajay Gupta (1):
nvidi
From: Ajay Gupta
Function is to get the details of ccg firmware and device version.
It will be useful in debugging and also during firmware update.
Signed-off-by: Ajay Gupta
---
Changes from v3 to v4
- None
drivers/usb/typec/ucsi/ucsi_ccg.c | 66 ++-
1
From: Ajay Gupta
CCGx has two copies of the firmware in addition to the bootloader.
If the device is running FW1, FW2 can be updated with the new version.
Dual firmware mode allows the CCG device to stay in a PD contract and
support USB PD and Type-C functionality while a firmware update is in
-request is posted to linux-firmware.git at [1].
Please help review this set.
Thanks
Ajay
[1] https://marc.info/?l=linux-usb&m=154948878626598&w=2
Ajay Gupta (2):
usb: typec: ucsi: add get_fw_info function
usb: typec: ucsi: add firmware flashing support
drivers/usb/typec/ucsi/ucsi_ccg
specific mutex lock is also added to sync between driver and
> > user threads.
> >
> > PD port number information is added which is required while sending
> > PD_PORT_ENABLE command
> >
> > Signed-off-by: Ajay Gupta
>
> [..]
>
> > +struct ccg_cmd {
> >
From: Ajay Gupta
CCGx has two copies of the firmware in addition to the bootloader.
If the device is running FW1, FW2 can be updated with the new version.
Dual firmware mode allows the CCG device to stay in a PD contract and
support USB PD and Type-C functionality while a firmware update is in
://marc.info/?l=linux-usb&m=154948878626598&w=2
Ajay Gupta (2):
usb: typec: ucsi: add get_fw_info function
usb: typec: ucsi: add firmware flashing support
drivers/usb/typec/ucsi/ucsi_ccg.c | 884 +-
1 file changed, 874 insertions(+), 10 deletions(-)
--
2.17.1
From: Ajay Gupta
Function is to get the details of ccg firmware and device version.
It will be useful in debugging and also during firmware update.
Signed-off-by: Ajay Gupta
---
Changes from v4 to v5
- None
drivers/usb/typec/ucsi/ucsi_ccg.c | 66 ++-
1
Hi Josh,
> On Wed, Feb 6, 2019 at 3:14 PM Ajay Gupta wrote:
> >
> > From: Ajay Gupta
> >
> > These NVIDIA-signed firmwares are required to enable the Cypress
> > Type-C controller on TU10x GPUs.
> >
> > FW versions:
> > Secondary: 4
Hi Josh
> -Original Message-
> From: linux-usb-ow...@vger.kernel.org On
> Behalf Of Josh Boyer
> Sent: Tuesday, February 12, 2019 4:51 AM
> To: Ajay Gupta
> Cc: linux-firmw...@kernel.org; Heikki Krogerus
> ; linux-usb@vger.kernel.org
> Subject: Re: [GIT,PULL]
101 - 200 of 219 matches
Mail list logo
