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, &data,
>>> sizeof(data));
>>>
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 h
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.
>>>
>>> Could
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 tre
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
>>> +
>>> +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,
>>
hould support 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
>
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 workin
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
hould support 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
>
[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 g
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;
>> +
S
> @@ -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-nvid
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;
+
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 even
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);
> +
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);
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) + USBC_MSG_OUT_OFFS
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,
>
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 */
>>
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)
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);
>> +
r GPU.
> diff --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
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. And
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
> Acked-by
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
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
>>> +
>>> +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 control
> 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
> +F: drivers/i2c/busses/i2c-nvidia-gpu
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
> Acked-by
NERS
> 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-...@v
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
> Acked-by
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 Type-C
AINTAINERS
> 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
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
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
>>
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 t
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 AM, Hans de Goede
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
wrote:
>
> Hi,
>
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 pola
On 2017-09-08 17:45, Peter Rosin wrote:
> 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 dri
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.
>
> Signed
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 de
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 xhci
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 connec
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 add
a mux_control_get_opt
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
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 code
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 +
> drivers/mux/Makefile |
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
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 d
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
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
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
> Cc: Peter Chen
> Cc: Greg Kroah-Hartman
> Cc:
> Signed-off-by:
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/
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
On 2017-07-14 23:27, Stephen Boyd wrote:
> Quoting Stephen Boyd (2017-07-13 15:35:02)
>> Quoting Peter Rosin (2017-07-11 22:04:46)
>>>
>>> Maybe no need for a compatible update either, if it works to do something
>>> like this in the DT?
&g
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
> Cc: Peter Chen
> Cc: Greg Kroah-Hartman
> Cc:
> Signed-off-by:
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 kn
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
s for ports outside num-ports.
WTF? Big sigh.
Fixes: 054d4b7b577d ("usb: ohci-at91: Use descriptor-based gpio APIs")
Signed-off-by: Peter Rosin
---
Hi!
Resending this, since the only response I've got is that the merge
window is open and that this patch has been put on hold due
s for ports outside num-ports.
WTF? Big sigh.
Fixes: 054d4b7b577d ("usb: ohci-at91: Use descriptor-based gpio APIs")
Signed-off-by: Peter Rosin
---
Hi!
Ok, I looked again and found one more problem with that garbage patch
(which did not affect me since I have just one port). You mig
b577d ("usb: ohci-at91: Use descriptor-based gpio APIs")
Signed-off-by: Peter Rosin
---
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
index 1b2e09c32c6
Signed-off-by: Peter Rosin
---
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
index f4262ed60582
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 []
>
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 tha
66 matches
Mail list logo