Il giorno gio, 06/06/2019 alle 16.47 +0200, Greg KH ha scritto:
>
>
> [...]
>
> As Alan said, 4.20 is older than 4.20.13.
Thank you Greg, and thank you Alan for your explanations.
>
> But, is the kernel.org version of 4.20.13 really "good" here?
>
> I would start with Linus's tree and stay a
On Mon, Jun 03, 2019 at 10:05:43AM -0700, Ajay Gupta wrote:
> From: Ajay Gupta
>
> The change enables runtime pm support to UCSI CCG driver.
> Added ucsi_resume() function to enable notification after
> system reusme. Exported both ucsi_resume() and ucsi_send_command()
> symbols in ucsi.c for mod
On Mon, Jun 03, 2019 at 10:05:45AM -0700, Ajay Gupta wrote:
> From: Ajay Gupta
>
> Cypress USB Type-C CCGx controller firmware version 3.1.10
> (which is being used in many NVIDIA GPU cards) has known issue of
> not triggering interrupt when a USB device is hot plugged to runtime
> resume the con
On Fri, Jun 07, 2019 at 11:25:10AM +0300, Heikki Krogerus wrote:
> On Mon, Jun 03, 2019 at 10:05:43AM -0700, Ajay Gupta wrote:
> > From: Ajay Gupta
> >
> > The change enables runtime pm support to UCSI CCG driver.
> > Added ucsi_resume() function to enable notification after
> > system reusme. Ex
> + pm_runtime_mark_last_busy(i2cd->dev);
> + pm_runtime_put_autosuspend(i2cd->dev);
Much better to have this only once!
> +/*
> + * We need gpu_i2c_suspend() even if it is stub, for runtime pm to work
> + * correctly. Without it, lspci shows runtime pm status as "D0" for the card.
> + *
> Changes from v3->v4:
> - Further refactor master_xfer based on Wolfram's comment.
Yay, looks even better. One thing to improve, though.
> status = gpu_i2c_stop(i2cd);
send_stop = false;
> - if (status < 0)
> - return status;
> + if (status < 0) {
> +
Hi John,
Now that we have dwc3_gadget_start_isoc_quirk() which figures out the
correct combination for the top-most 2 bits in the frame number, why
don't we just use that to start isochronous transfers and never, again,
have Bus Expiry problems?
I mean something along the lines of below diff (co
Hi Alan,
I've noticed that when the host performs a control request,
urb->transfer_buffer/transfer_buffer_length are not passed to the
gadget drivers via the setup() call, the only thing that is passed is
the usb_ctrlrequest struct. Is there a way to get the transfer_buffer
from within a gadget dr
Hi,
Andrey Konovalov writes:
> I've noticed that when the host performs a control request,
> urb->transfer_buffer/transfer_buffer_length are not passed to the
> gadget drivers via the setup() call, the only thing that is passed is
> the usb_ctrlrequest struct. Is there a way to get the transfer_
On Fri, Jun 7, 2019 at 2:02 PM Felipe Balbi
wrote:
>
>
> Hi,
>
> Andrey Konovalov writes:
> > I've noticed that when the host performs a control request,
> > urb->transfer_buffer/transfer_buffer_length are not passed to the
> > gadget drivers via the setup() call, the only thing that is passed is
Hi,
Andrey Konovalov writes:
>> Andrey Konovalov writes:
>> > I've noticed that when the host performs a control request,
>> > urb->transfer_buffer/transfer_buffer_length are not passed to the
>> > gadget drivers via the setup() call, the only thing that is passed is
>> > the usb_ctrlrequest st
On Fri, Jun 7, 2019 at 2:25 PM Felipe Balbi
wrote:
>
>
> Hi,
>
> Andrey Konovalov writes:
> >> Andrey Konovalov writes:
> >> > I've noticed that when the host performs a control request,
> >> > urb->transfer_buffer/transfer_buffer_length are not passed to the
> >> > gadget drivers via the setup(
Hi,
Andrey Konovalov writes:
>> >> Andrey Konovalov writes:
>> >> > I've noticed that when the host performs a control request,
>> >> > urb->transfer_buffer/transfer_buffer_length are not passed to the
>> >> > gadget drivers via the setup() call, the only thing that is passed is
>> >> > the usb
On Fri, Jun 7, 2019 at 2:43 PM Felipe Balbi
wrote:
>
>
> Hi,
>
> Andrey Konovalov writes:
> >> >> Andrey Konovalov writes:
> >> >> > I've noticed that when the host performs a control request,
> >> >> > urb->transfer_buffer/transfer_buffer_length are not passed to the
> >> >> > gadget drivers vi
The devm_memremap() function doesn't return NULL, it returns error
pointers.
Fixes: b0310c2f09bb ("USB: use genalloc for USB HCs with local memory")
Signed-off-by: Dan Carpenter
---
drivers/usb/core/hcd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/hc
On Fri, Jun 07, 2019 at 12:03:01PM +0530, Prabhat Chand Pandey wrote:
> This patch-set adds the following features to dbc driver:
>
> - show the active dbc function and dbc descriptors, allowing
> user space to dynamically modify the descriptors.
Why would we want userspace to modify these?
>
On Fri, Jun 07, 2019 at 12:03:02PM +0530, Prabhat Chand Pandey wrote:
> This patch introduces the dbc_function structure as a first step in
> making DbC modular and capable in exposing different user interfaces using
> different "functions", which may implement the callbacks exposed here
> accordin
On Fri, 7 Jun 2019, Andrey Konovalov wrote:
> On Fri, Jun 7, 2019 at 2:43 PM Felipe Balbi
> wrote:
> >
> >
> > Hi,
> >
> > Andrey Konovalov writes:
> > >> >> Andrey Konovalov writes:
> > >> >> > I've noticed that when the host performs a control request,
> > >> >> > urb->transfer_buffer/transfe
On Fri, Jun 07, 2019 at 12:03:03PM +0530, Prabhat Chand Pandey wrote:
> Change DbC TTY driver to use the new modular interface exposed by the DbC
> core. This will allow other function drivers with a different interface
> also to use DbC.
What are those other function drivers? What is wrong with
On Fri, Jun 07, 2019 at 12:03:04PM +0530, Prabhat Chand Pandey wrote:
> From: "K V, Abhilash"
>
> Show the active dbc function and dbc descriptors, allowing
> user space to dynamically modify the descriptors
>
> The DBC specific sysfs attributes are separated into two groups,
> in the first grou
On Fri, Jun 07, 2019 at 12:03:05PM +0530, Prabhat Chand Pandey wrote:
> From: Abhilash K V
>
> This patch provides a raw device interface on xhci Debug capability.
What is a "raw device"?
> This abstracts dbc functionality to user space inorder to facilitate
> various frameworks to utilize xhci
On Fri, Jun 07, 2019 at 12:03:06PM +0530, Prabhat Chand Pandey wrote:
> This patch have explaination about the new DBC interface called
> dbc raw interface. This cover the capability, target setup and
> use case info.
>
> Signed-off-by: Prabhat Chand Pandey
> ---
I want to see this signed off by
On Fri, Jun 7, 2019 at 4:04 PM Alan Stern wrote:
>
> On Fri, 7 Jun 2019, Andrey Konovalov wrote:
>
> > On Fri, Jun 7, 2019 at 2:43 PM Felipe Balbi
> > wrote:
> > >
> > >
> > > Hi,
> > >
> > > Andrey Konovalov writes:
> > > >> >> Andrey Konovalov writes:
> > > >> >> > I've noticed that when the
On Fri, 7 Jun 2019, Andrey Konovalov wrote:
> > > The problem is that I want to receive that data (from the data stage)
> > > from within my gadget driver module. But it's not passed to the
> > > setup() callback. And the question is: how do I do that then?
> >
> > I just caught up on this thread.
On Fri, Jun 7, 2019 at 5:02 PM Alan Stern wrote:
>
> On Fri, 7 Jun 2019, Andrey Konovalov wrote:
>
> > > > The problem is that I want to receive that data (from the data stage)
> > > > from within my gadget driver module. But it's not passed to the
> > > > setup() callback. And the question is: ho
Hi Heikki and Wolfram,
> -Original Message-
> From: linux-i2c-ow...@vger.kernel.org
> On Behalf Of Wolfram Sang
> Sent: Friday, June 7, 2019 1:27 AM
> To: Heikki Krogerus
> Cc: Ajay Gupta ; linux-usb@vger.kernel.org; linux-
> i...@vger.kernel.org; Ajay Gupta
> Subject: Re: [PATCH v4 3/5
Hi Wolfram,
> -Original Message-
> From: Wolfram Sang
> Sent: Friday, June 7, 2019 1:33 AM
> To: Ajay Gupta
> Cc: heikki.kroge...@linux.intel.com; linux-usb@vger.kernel.org; linux-
> i...@vger.kernel.org; Ajay Gupta
> Subject: Re: [PATCH v4 1/5] i2c: nvidia-gpu: refactor master_xfer
>
Hi Wolfram,
> -Original Message-
> From: linux-i2c-ow...@vger.kernel.org
> On Behalf Of Wolfram Sang
> Sent: Friday, June 7, 2019 1:33 AM
> To: Ajay Gupta
> Cc: heikki.kroge...@linux.intel.com; linux-usb@vger.kernel.org; linux-
> i...@vger.kernel.org; Ajay Gupta
> Subject: Re: [PATCH v4
From: Ajay Gupta
Added a local variable "send_stop" to simplify "goto" statements.
The "send_stop" handles below two case
1) When first i2c start fails and so i2c stop is not sent before
exiting
2) When i2c stop failed after all transfers and we do not need to
send another stop before exiting.
Hi Heikki and Wolfram
The latest set (v5) fix comments from Wolfram on further refactoring
master_xfer() function in i2c-nvidia-gpuc.c file and removing extra comments
in patch 2/5.
Patches can go through either usb or i2c tree but since there are 3 out of 5
patches from i2c so may be better they
From: Ajay Gupta
Cypress USB Type-C CCGx controller firmware version 3.1.10
(which is being used in many NVIDIA GPU cards) has known issue of
not triggering interrupt when a USB device is hot plugged to runtime
resume the controller. If any GPU card gets latest kernel with runtime
pm support but
From: Ajay Gupta
The change enables runtime pm support to UCSI CCG driver.
Added ucsi_resume() function to enable notification after
system reusme. Exported both ucsi_resume() and ucsi_send_command()
symbols in ucsi.c for modular build.
Signed-off-by: Ajay Gupta
Acked-by: Heikki Krogerus
---
C
From: Ajay Gupta
Enable runtime pm support with autosuspend delay of three second.
This is to make sure I2C client device Cypress CCGx has completed
all transaction.
Signed-off-by: Ajay Gupta
---
Changes from v4->v5:
- Removed extra comments for gpu_i2c_suspend() based on
Wolfra
From: Ajay Gupta
Cypress USB Type-C CCGx controller firmware version 3.1.10
(which is being used in many NVIDIA GPU cards) has known issue of
not triggering interrupt when a USB device is hot plugged to runtime
resume the controller. If any GPU card gets latest kernel with runtime
pm support but
On Fri, Jun 07, 2019 at 09:34:18AM -0700, Ajay Gupta wrote:
> Hi Heikki and Wolfram
> The latest set (v5) fix comments from Wolfram on further refactoring
> master_xfer() function in i2c-nvidia-gpuc.c file and removing extra comments
> in patch 2/5.
>
> Patches can go through either usb or i2c tre
For some wanted baud rates ch341_set_baudrate_lcr() calculates the "a"
value such that it produces a significantly different baud rate than the
desired one. This means some hardware can't communicate with the CH34x
chip. Particularly obvious wrong baud rates are 256000 and 921600 which
deviate by 2
36 matches
Mail list logo
