Re: Regression, was [PATCH 4/4] USB: host: ohci-at91: merge loops in ohci_hcd_at91_drv_probe

Hi Alexandre, On 2015-12-02 19:20, Alexandre Belloni wrote: > Hi Peter, > > On 01/12/2015 at 18:17:16 +0100, Peter Rosin wrote : >> [] (ohci_hcd_at91_overcurrent_irq) from [] >> (handle_irq_event_percpu+0x78/0x140) >> [] (handle_irq_event_percpu) from [] >

Regression, was [PATCH 4/4] USB: host: ohci-at91: merge loops in ohci_hcd_at91_drv_probe

Hi! Alexandre Belloni wrote: > ohci_hcd_at91_drv_probe() has four at91_for_each_port. They can be merged > into two loops without changing the driver behaviour. Not so much, I bisected the following panic to the commit matching this patch (e4df92279fd9e01532f65e5ba397877799ed6252). Reverting

[PATCH] dt-bindings: usb: atmel: fix a couple of copy-paste style typos

Signed-off-by: Peter Rosin <p...@axentia.se> --- Documentation/devicetree/bindings/usb/atmel-usb.txt | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt

[PATCH] usb: ohci-at91: use descriptor-based gpio APIs correctly

("usb: ohci-at91: Use descriptor-based gpio APIs") Signed-off-by: Peter Rosin <p...@axentia.se> --- drivers/usb/host/ohci-at91.c | 20 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c in

[PATCH v2] usb: ohci-at91: use descriptor-based gpio APIs correctly

for ports outside num-ports. WTF? Big sigh. Fixes: 054d4b7b577d ("usb: ohci-at91: Use descriptor-based gpio APIs") Signed-off-by: Peter Rosin <p...@axentia.se> --- Hi! Ok, I looked again and found one more problem with that garbage patch (which did not affect me since I have jus

Re: [PATCH v2 REGRESSION RESEND] usb: ohci-at91: use descriptor-based gpio APIs correctly

On 2016-12-22 18:27, Greg Kroah-Hartman wrote: > On Thu, Dec 22, 2016 at 08:43:55AM +0100, Peter Rosin wrote: >> The gpiod_get* function family does not want the -gpio suffix. >> Use devm_gpiod_get_index_optional instead of devm_gpiod_get_optional. >> The descriptor based AP

[PATCH v2 REGRESSION RESEND] usb: ohci-at91: use descriptor-based gpio APIs correctly

for ports outside num-ports. WTF? Big sigh. Fixes: 054d4b7b577d ("usb: ohci-at91: Use descriptor-based gpio APIs") Signed-off-by: Peter Rosin <p...@axentia.se> --- Hi! Resending this, since the only response I've got is that the merge window is open and that this patch has been

Re: [PATCH v2 2/3] usb: chipidea: Hook into mux framework to toggle usb switch

tation/ABI/testing/sysfs-platform-chipidea-usb2. > > [1] > https://github.com/96boards/documentation/raw/master/ConsumerEdition/DragonBoard-410c/HardwareDocs/Schematics_DragonBoard.pdf > > Cc: Peter Rosin <p...@axentia.se> > Cc: Peter Chen <peter.c...@nxp.com> > Cc: G

Re: [PATCH v2 2/3] usb: chipidea: Hook into mux framework to toggle usb switch

On 2017-08-12 00:26, Stephen Boyd wrote: > Quoting Peter Rosin (2017-08-08 05:46:30) >> On 2017-08-08 03:51, Stephen Boyd wrote: >> >>> It looked like we paired the start/stop ops with >>> each other so that the mux is properly managed acros

Re: [PATCH 2/3] usb: chipidea: Hook into mux framework to toggle usb switch

tation/ABI/testing/sysfs-platform-chipidea-usb2. > > [1] > https://github.com/96boards/documentation/raw/master/ConsumerEdition/DragonBoard-410c/HardwareDocs/Schematics_DragonBoard.pdf > > Cc: Peter Rosin <p...@axentia.se> > Cc: Peter Chen <peter.c...@nxp.com> > Cc: G

Re: [PATCH 0/3] USB Mux support for Chipidea

On 2017-07-12 03:02, Stephen Boyd wrote: > This patchset adds support for the TC7USB40MU usb mux found on > db410c 96boards platforms via the new multiplexer framework and > hooks that into the chipidea driver. This allows us to properly > control host or device mode on this board via the sysfs

Re: [PATCH v2 1/3] mux: Add mux_control_get_optional() API

Generally looks like I imagined, but there are a few nits and some things that I'd like to do differently. Comments inline. Thanks! On 2017-07-14 23:40, Stephen Boyd wrote: > Sometimes drivers only use muxes under certain scenarios. For > example, the chipidea usb controller may be connected to a

Re: [PATCH v2 1/3] mux: Add mux_control_get_optional() API

On 2017-07-19 04:08, Stephen Boyd wrote: > Quoting Peter Rosin (2017-07-17 01:20:14) >> On 2017-07-14 23:40, Stephen Boyd wrote: >>> diff --git a/drivers/mux/mux-core.c b/drivers/mux/mux-core.c >>> index 90b8995f07cb..a0e5bf16f02f 100644 >>> --- a/drivers/mux/

Re: [PATCH v2 2/3] usb: chipidea: Hook into mux framework to toggle usb switch

On 2017-08-08 03:51, Stephen Boyd wrote: > Quoting Peter Rosin (2017-07-31 03:33:22) >> On 2017-07-14 23:40, Stephen Boyd wrote: >>> @@ -1964,16 +1965,26 @@ void ci_hdrc_gadget_destroy(struct ci_hdrc *ci) >>> >>> static int udc_id_switch_for_device(struct c

[PATCH 1/2] mux: add mux_control_get_optional() API

From: Stephen Boyd Sometimes drivers only use muxes under certain scenarios. For example, the chipidea usb controller may be connected to a usb switch on some platforms, and connected directly to a usb port on others. The driver won't know one way or the other though, so

Re: [PATCH v2 05/11] mux: Add Intel Cherrytrail USB mux driver

On 2017-09-05 18:42, Hans de Goede wrote: > Intel Cherrytrail SoCs have an internal USB mux for muxing the otg-port > USB data lines between the xHCI host controller and the dwc3 gadget > controller. On some Cherrytrail systems this mux is controlled through > AML code reacting on a GPIO IRQ

Re: [PATCH 1/2] mux: add mux_control_get_optional() API

On 2017-09-08 17:45, Peter Rosin wrote: > From: Stephen Boyd <stephen.b...@linaro.org> > > Sometimes drivers only use muxes under certain scenarios. For > example, the chipidea usb controller may be connected to a usb > switch on some platforms, and connected directly to a

Re: [PATCH v2 04/11] usb: xhci: Add Intel cherrytrail extended cap / otg phy mux handling

On 2017-09-05 18:42, Hans de Goede wrote: > The Intel cherrytrail xhci controller has an extended cap mmio-range > which contains registers to control the muxing to the xhci (host mode) > or the dwc3 (device mode) and vbus-detection for the otg usb-phy. > > Having a mux driver included in the

[PATCH 2/2] mux: add explicit hook to leave the mux as-is on init/registration

A board may need a mux controller to stay as-is for a while longer, e.g. if setting the normally preferred idle state destroys booting. The mechanism provided here is not perfect in two ways. 1. As soon as the mux controller is registered, some mux consumer can access it and set a state that

Re: [PATCH v2 03/11] mux: core: Add usb.h header with MUX_USB_* and and MUX_TYPEC_* state constants

On 2017-09-05 18:42, Hans de Goede wrote: > Add MUX_USB_* and MUX_TYPEC_* state constant defines, which can be used by > USB device/host, resp. Type-C polarity/role/altmode mux drivers and > consumers to ensure that they agree on the meaning of the > mux_control_select() state argument. > >

Re: [PATCH 06/11] mux: Add Pericom PI3USB30532 Type-C mux driver

On 2017-09-04 13:19, Peter Rosin wrote: > Hi! > > One comment inline... Oh, and one more small nit, I think you should do s/pi3usb30532_mux/pi3usb30532/g to shorten the identifiers a bit. The _mux suffix (or infix) is kind of selfevident from where the file liv

Re: [PATCH v2 03/11] mux: core: Add usb.h header with MUX_USB_* and and MUX_TYPEC_* state constants

On 2017-09-08 19:07, Hans de Goede wrote: > Hi, > > On 08-09-17 17:47, Peter Rosin wrote: >> On 2017-09-05 18:42, Hans de Goede wrote: >>> Add MUX_USB_* and MUX_TYPEC_* state constant defines, which can be used by >>> USB device/host, resp. Type-C

Re: [PATCH v2 10/11] staging: typec: fusb302: Hook up mux support using tcpc_gen_mux support

On 2017-09-25 13:35, Hans de Goede wrote: > Hi, > > On 25-09-17 12:34, Peter Rosin wrote: >> On 2017-09-13 17:48, Hans de Goede wrote: >>> Hi, >>> >>> On 13-09-17 17:07, Rob Herring wrote: >>>> On Wed, Sep 13, 2017 at 9:06 A

Re: [PATCH v2 10/11] staging: typec: fusb302: Hook up mux support using tcpc_gen_mux support

On 2017-09-13 17:48, Hans de Goede wrote: > Hi, > > On 13-09-17 17:07, Rob Herring wrote: >> On Wed, Sep 13, 2017 at 9:06 AM, Hans de Goede wrote: >>> Hi, >>> >>> >>> On 13-09-17 15:38, Rob Herring wrote: On Wed, Sep 13, 2017 at 3:56 AM, Hans de Goede

Re: [PATCH 00/11] mux/typec: Add USB / TypeC mux drivers and hook them up on some x86 systems

On 2017-09-01 23:48, Hans de Goede wrote: > Hi All, > > This series consists of 4 parts: > > 1) Core mux changes to add support for getting mux-controllers on >non DT platforms and to add some standardised state values for USB > > 2) Add Intel CHT USB mux and Pericom-PI3USB30532 Type-C mux

Re: [PATCH 05/11] mux: Add Intel Cherrytrail USB mux driver

Hi! Some comments inline... On 2017-09-01 23:48, Hans de Goede wrote: > Intel Cherrytrail SoCs have an internal USB mux for muxing the otg-port > USB data lines between the xHCI host controller and the dwc3 gadget > controller. On some Cherrytrail systems this mux is controlled through > AML

Re: [PATCH 02/11] mux: core: Add support for getting a mux controller on a non DT platform

Hi! Some comments inline... On 2017-09-01 23:48, Hans de Goede wrote: > On non DT platforms we cannot get the mux_chip by pnode. Other subsystems > (regulator, clock, pwm) have the same problem and solve this by allowing > platform / board-setup code to add entries to a lookup table and then use

Re: [PATCH 06/11] mux: Add Pericom PI3USB30532 Type-C mux driver

Hi! One comment inline... On 2017-09-01 23:48, Hans de Goede wrote: > Add a driver for the Pericom PI3USB30532 Type-C cross switch / > mux chip found on some devices with a Type-C port. > > Signed-off-by: Hans de Goede > --- > drivers/mux/Kconfig | 10 + >

Re: [PATCH v2] usb: chipidea: Hook into mux framework to toggle usb switch

On 2018-04-18 07:48, yos...@codeaurora.org wrote: > On 2018-04-17 17:11, Peter Rosin wrote: >> On 2018-04-17 15:52, Yossi Mansharoff wrote: >>> On the db410c 96boards platform we have a TC7USB40MU on the board >>> to mux the D+/D- lines coming from the controller betw

Re: [PATCH v9 1/2] i2c: buses: add i2c bus driver for NVIDIA GPU

>>> + >>> +If your 'lspci -v' listing shows something like the following, >>> + >>> +01:00.3 Serial bus controller [0c80]: NVIDIA Corporation Device 1ad9 >>> +(rev a1) >>> + >>> +then this driver should support the I2C controller of you

Re: [PATCH v9 2/2] usb: typec: ucsi: add support for Cypress CCGx

On 2018-09-07 19:28, Ajay Gupta wrote: > 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

Re: [PATCH v10 1/2] i2c: buses: add i2c bus driver for NVIDIA GPU

f --git a/MAINTAINERS b/MAINTAINERS > index 9ad052a..2d1c5a1 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6797,6 +6797,13 @@ L: linux-a...@vger.kernel.org > S: Maintained > F: drivers/i2c/i2c-core-acpi.c > > +I2C CONTROLLER DRIVER FOR NVIDIA GPU > +M:

Re: [PATCH v6 1/2] i2c: buses: add i2c bus driver for NVIDIA GPU

> index 9ad052a..2d1c5a1 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6797,6 +6797,13 @@ L: linux-a...@vger.kernel.org > S: Maintained > F: drivers/i2c/i2c-core-acpi.c > > +I2C CONTROLLER DRIVER FOR NVIDIA GPU > +M: Ajay Gupta > +L: linux-...@vger.

Re: [PATCH v7 2/2] usb: typec: ucsi: add support for Cypress CCGx

On 2018-09-06 20:10, Ajay Gupta wrote: > 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 >

Re: [PATCH v6 1/2] i2c: buses: add i2c bus driver for NVIDIA GPU

On 2018-09-06 19:39, Ajay Gupta wrote: > Hi Peter, > >>> 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

Re: [PATCH v9 1/2] i2c: buses: add i2c bus driver for NVIDIA GPU

Maintained > F: drivers/i2c/i2c-core-acpi.c > > +I2C CONTROLLER DRIVER FOR NVIDIA GPU > +M: Ajay Gupta > +L: linux-...@vger.kernel.org > +S: Maintained > +F: Documentation/i2c/busses/i2c-nvidia-gpu > +F: drivers/i2c/busses/i2c-nvidia-gpu.c > +

Re: [PATCH v9 2/2] usb: typec: ucsi: add support for Cypress CCGx

On 2018-09-07 01:56, Ajay Gupta wrote: > 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 >

Re: [PATCH v8 1/2] i2c: buses: add i2c bus driver for NVIDIA GPU

gt; index 9ad052a..2d1c5a1 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6797,6 +6797,13 @@ L: linux-a...@vger.kernel.org > S: Maintained > F: drivers/i2c/i2c-core-acpi.c > > +I2C CONTROLLER DRIVER FOR NVIDIA GPU > +M: Ajay Gupta > +L: linux-...@vger.kernel

Re: [PATCH v10 1/2] i2c: buses: add i2c bus driver for NVIDIA GPU

On 2018-09-08 21:17, Peter Rosin wrote: >> + >> +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); >> +

Re: [PATCH v10 1/2] i2c: buses: add i2c bus driver for NVIDIA GPU

On 2018-09-10 19:28, Peter Rosin wrote: > On 2018-09-10 18:08, Ajay Gupta wrote: >> Hi Peter, >> >>>>> + >>>>> + if (msgs[i].flags & I2C_M_RD) { >>>>> + /* gpu_i2c_read has implicit start and stop */ >>

Re: [PATCH v10 1/2] i2c: buses: add i2c bus driver for NVIDIA GPU

On 2018-09-10 18:08, Ajay Gupta wrote: > 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)

Re: [PATCH v10 2/2] usb: typec: ucsi: add support for Cypress CCGx

On 2018-09-10 19:32, Ajay Gupta wrote: >>> +static int ccg_read(struct ucsi_ccg *uc, u16 rab, u8 *data, u32 len) >>> +{ >>> + struct i2c_client *client = uc->client; >>> + unsigned char buf[2]; >>> + struct i2c_msg msgs[] = { >>> + { >>> + .addr = client->addr,

Re: [PATCH v10 1/2] i2c: buses: add i2c bus driver for NVIDIA GPU

On 2018-09-10 19:43, Ajay Gupta wrote: > 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);

Re: [PATCH v10 1/2] i2c: buses: add i2c bus driver for NVIDIA GPU

On 2018-09-10 22:04, Ajay Gupta wrote: > 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); > +

Re: [PATCH v10 2/2] usb: typec: ucsi: add support for Cypress CCGx

On 2018-09-10 20:51, Ajay Gupta wrote: > +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) +

Re: [PATCH v10 2/2] usb: typec: ucsi: add support for Cypress CCGx

On 2018-09-10 23:53, Ajay Gupta wrote: > 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; +

Re: [PATCH v11 1/2] i2c: buses: add i2c bus driver for NVIDIA GPU

-6798,6 +6798,13 @@ L: linux-a...@vger.kernel.org > S: Maintained > F: drivers/i2c/i2c-core-acpi.c > > +I2C CONTROLLER DRIVER FOR NVIDIA GPU > +M: Ajay Gupta > +L: linux-...@vger.kernel.org > +S: Maintained > +F: Documentation/i2c/busses/i2c-nvidia-gpu >

Re: [PATCH v10 1/2] i2c: buses: add i2c bus driver for NVIDIA GPU

On 2018-09-10 23:38, Ajay Gupta wrote: >> My guess is that with the above, you can actually program the I2C_MST_ADDR >> register inside the "if (Read)" branch and then remove the I2C_AQ_COMB | >> I2C_AQ_COMB_WRITE_FIRST | I2C_AQ_COMB_SAME_ADDR quirks. > > We need I2C_MST_ADDR to be programmed

Re: [PATCH v10 2/2] usb: typec: ucsi: add support for Cypress CCGx

On 2018-09-08 02:09, Ajay Gupta wrote: > 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 >

RE: [PATCH v9 1/2] i2c: buses: add i2c bus driver for NVIDIA GPU

On September 7, 2018 11:48:37 PM GMT+02:00, Ajay Gupta wrote: >> >> Per your comments on v8, the address has to be programmed before >the >> >> transfer, but you fail to do that if the first message is a read. >> > This will never happen. Hint: I2C_AQ_COMB_WRITE_FIRST >> >> Yes, it will. If the

Re: [PATCH v9 1/2] i2c: buses: add i2c bus driver for NVIDIA GPU

On 2018-09-08 16:13, Ajay Gupta wrote: > > 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.

Re: [PATCH v11 1/2] i2c: buses: add i2c bus driver for NVIDIA GPU

[I seem to have lost my local copy of the mail I'm responding to, so I copied bits of it from an archive and broke threading in the process, sorry about that] On 2018-09-11 00:22, Ajay Gupta wrote: >> Hmm, that goto stop is however not perfect. Ideally, >> you shouldn't issue stop if i == 0 and

Re: [PATCH v10 2/2] usb: typec: ucsi: add support for Cypress CCGx

On 2018-09-11 06:30, Ajay Gupta wrote: > 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; >> +

Re: [PATCH v2] usb: chipidea: Hook into mux framework to toggle usb switch

On 2018-04-17 15:52, Yossi Mansharoff wrote: > On the db410c 96boards platform we have a TC7USB40MU on the board > to mux the D+/D- lines coming from the controller between a micro > usb "device" port and a USB hub for "host" roles[1]. During a > role switch, we need to toggle this mux to forward

Re: [PATCH v2] usb: chipidea: Hook into mux framework to toggle usb switch

On 2018-04-20 04:00, Peter Chen wrote: > > >> --- a/drivers/usb/chipidea/Kconfig >> +++ b/drivers/usb/chipidea/Kconfig >> @@ -3,6 +3,8 @@ config USB_CHIPIDEA >> depends on ((USB_EHCI_HCD && USB_GADGET) || (USB_EHCI_HCD >> && !USB_GADGET) || (!USB_EHCI_HCD && USB_GADGET)) && HAS_DMA >>

Re: [PATCH v12 1/2] i2c: buses: add i2c bus driver for NVIDIA GPU

On 2018-10-02 09:27, Wolfram Sang wrote: > Hi, > 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. >>> >>>

Re: [PATCH v13 2/2] usb: typec: ucsi: add support for Cypress CCGx

On 2018-10-25 23:55, Ajay Gupta wrote: > Hi Heikki 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, , >>> sizeof(data)); >>> if

Re: [PATCH v13 2/2] usb: typec: ucsi: add support for Cypress CCGx

On 2018-10-25 10:17, Heikki Krogerus wrote: > Hi, > > On Tue, Oct 23, 2018 at 06:56:59PM +, Ajay Gupta wrote: + /* i2c adapter (ccgx-ucsi) can read 4 byte max */ >>> >>> By "i2c adapter" do you mean this Cypress CCGx controller, or the NVIDIA I2C >>> host adapter? >> It mean NVIDIA I2C

Re: [PATCH v12 1/2] i2c: buses: add i2c bus driver for NVIDIA GPU

On 2018-10-01 21:33, Ajay Gupta wrote: > 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

Re: [PATCH v12 1/2] i2c: buses: add i2c bus driver for NVIDIA GPU

>>> + >>> +i2c-nvidia-gpu is a driver for I2C controller included in NVIDIA >>> +Turing and later GPUs and it is used to communicate with Type-C controller >> on GPUs. >>> + >>> +If your 'lspci -v' listing shows something like the following, >>> + >

Re: [PATCH v12 1/2] i2c: buses: add i2c bus driver for NVIDIA GPU

On 2018-09-13 00:22, Ajay Gupta wrote: > Hi 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

Re: [PATCH v11 1/2] i2c: buses: add i2c bus driver for NVIDIA GPU

On 2018-09-11 18:53, Ajay Gupta wrote: > 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

Re: [PATCH v12 1/2] i2c: buses: add i2c bus driver for NVIDIA GPU

ort the I2C controller of your GPU. > diff --git a/MAINTAINERS b/MAINTAINERS > index d870cb5..b71b0b4 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6798,6 +6798,13 @@ L: linux-a...@vger.kernel.org > S: Maintained > F: drivers/i2c/i2c-core-acpi.c > > +

Re: [PATCH v12 1/2] i2c: buses: add i2c bus driver for NVIDIA GPU

ort the I2C controller of your GPU. > diff --git a/MAINTAINERS b/MAINTAINERS > index d870cb5..b71b0b4 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6798,6 +6798,13 @@ L: linux-a...@vger.kernel.org > S: Maintained > F: drivers/i2c/i2c-core-acpi.c > > +

Re: [PATCH v12 1/2] i2c: buses: add i2c bus driver for NVIDIA GPU

On 2018-09-12 00:48, Ajay Gupta wrote: >> If it doesn't work, maybe you can tweak something in gpu_i2c_read_byte to >> make it work? > I tried a few tweaks but it didn't work that way. I think it may take time to > get > this part working. > > Can we update this part later when we have it