On Tue, Oct 23, 2018 at 06:56:59PM +, Ajay Gupta wrote:
> > 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 uses I2C bus driver interface for communicating
On Thu, 18 Oct 2018 13:42:46 -0400
Alan Stern wrote:
> On Thu, 18 Oct 2018, Mayuresh Kulkarni wrote:
>
> > > The only way to make the ioctl work properly is to have it do a
> > > runtime-PM put at the start and then a runtime-PM get before it
> > > returns. This is true regardless of the reas
On Mon, 22 Oct 2018 10:24:46 -0400
Alan Stern wrote:
> On Mon, 22 Oct 2018, Oliver Neukum wrote:
>
> > On Do, 2018-10-18 at 13:42 -0400, Alan Stern wrote:
> > > On Thu, 18 Oct 2018, Mayuresh Kulkarni wrote:
> > >
> > > > > The only way to make the ioctl work properly is to have it do a
> > > >
On Wed, 24 Oct 2018, Mayuresh Kulkarni wrote:
> On Mon, 22 Oct 2018 10:24:46 -0400
> Alan Stern wrote:
>
> > On Mon, 22 Oct 2018, Oliver Neukum wrote:
> >
> > > On Do, 2018-10-18 at 13:42 -0400, Alan Stern wrote:
> > > > On Thu, 18 Oct 2018, Mayuresh Kulkarni wrote:
> > > >
> > > > > > The onl
Hi Joseph, Hi Bin,
I am currently investigating a bug with the BeagleBoneBlack (which also
uses the AM335x) and a Logitech Webcam, which might be connected.
I am using a Logitech C270 and if I set the format to YUYV and the
framesize to 544x288 or larger (including specifically 640x480), any
ioct
On Wed, 24 Oct 2018 10:10:32 -0400
Alan Stern wrote:
> On Wed, 24 Oct 2018, Mayuresh Kulkarni wrote:
>
> > On Mon, 22 Oct 2018 10:24:46 -0400
> > Alan Stern wrote:
> >
> > > On Mon, 22 Oct 2018, Oliver Neukum wrote:
> > >
> > > > On Do, 2018-10-18 at 13:42 -0400, Alan Stern wrote:
> > > > > O
Joel,
On Wed, Oct 24, 2018 at 05:31:25PM +0200, Joel Pepper wrote:
> Hi Joseph, Hi Bin,
>
> I am currently investigating a bug with the BeagleBoneBlack (which also
> uses the AM335x) and a Logitech Webcam, which might be connected.
>
> I am using a Logitech C270 and if I set the format to YUYV a
On Wed, 24 Oct 2018, Mayuresh Kulkarni wrote:
> > > In such a case, since user-space is waiting in "new" ioctl, it is not
> > > in position to queue a request to read-out the async event info. It
> > > will be able to queue a request when the "new" ioctl returns which
> > > will be "time-out" late
I am developing a custom USB device that makes use of isochronous IN
transfers. It works fine from my laptop (xHCI) however on an embedded
target (vortex86dx3, EHCI) I am seeing mysterious EFBIG errors. After
adding lots of debug to ehci-sched I discovered that the EHCI register
"FRINDEX" which i
Hi Joel,
The camera I have provides 640x480 as its lowest resolution.
Hope the issue can be solved.
Regards
On Wed, Oct 24, 2018 at 5:31 PM Joel Pepper wrote:
>
> Hi Joseph, Hi Bin,
>
> I am currently investigating a bug with the BeagleBoneBlack (which also
> uses the AM335x) and a Logitech Webc
On Wed, Oct 24, 2018 at 9:48 AM Daniel Goertzen
wrote:
>
> I am developing a custom USB device that makes use of isochronous IN
> transfers. It works fine from my laptop (xHCI) however on an embedded
> target (vortex86dx3, EHCI) I am seeing mysterious EFBIG errors. After
> adding lots of debug t
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
Hello!
On 10/24/2018 04:51 PM, Jarkko Nikula wrote:
> Platform drivers don't need dummy runtime PM callbacks that just return
> success in order to have runtime PM happening. This has changed since
> following commits:
>
> 05aa55dddb9e ("PM / Runtime: Lenient generic runtime pm callbacks")
> 543
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
On Wed, 24 Oct 2018, Daniel Goertzen wrote:
> I am developing a custom USB device that makes use of isochronous IN
> transfers. It works fine from my laptop (xHCI) however on an embedded
> target (vortex86dx3, EHCI) I am seeing mysterious EFBIG errors. After
> adding lots of debug to ehci-sched
On Wed, 24 Oct 2018, Steve Calfee wrote:
> On Wed, Oct 24, 2018 at 9:48 AM Daniel Goertzen
> wrote:
> >
> > I am developing a custom USB device that makes use of isochronous IN
> > transfers. It works fine from my laptop (xHCI) however on an embedded
> > target (vortex86dx3, EHCI) I am seeing my
Joel,
On Wed, Oct 24, 2018 at 07:19:01PM +0200, Josep M. Mirats Tur wrote:
> Hi Joel,
>
> The camera I have provides 640x480 as its lowest resolution.
> Hope the issue can be solved.
If your issue was same as mine - the uvc layer holds spinlock for too
long in urb->complete() which prevents musb
On Wed, Oct 24, 2018 at 05:46:22PM +, Ajay Gupta wrote:
> 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?
> >
> > Ye
Hi,
There are multiple reports[1][2][3] (more elsewhere on the internet) of USB 3
GbE adapters throwing EPROTO errors on USB transfer especially when the devices
are under load. Both of the two common chipsets (Realtek RTL8153 (r8152[4]) and
Asix AX88179 (ax88179_178a[5])) seem to exhibit this be
On Wed, Oct 17, 2018 at 11:30 PM Al Cooper wrote:
>
> Add support for Broadcom STB SoC's to the ohci platform driver.
>
> Signed-off-by: Al Cooper
> ---
> drivers/usb/host/ohci-platform.c | 35 +--
> include/linux/usb/ohci_pdriver.h | 1 +
> 2 files changed, 30 i
On Wed, Oct 17, 2018 at 11:30 PM Al Cooper wrote:
> +
> +static int ehci_brcm_probe(struct platform_device *pdev)
> +{
> + struct usb_hcd *hcd;
> + struct resource *res_mem;
> + struct brcm_priv *priv;
> + int irq;
> + int err;
> +
> + if (usb_disabled())
> +
Hi,
This is based on Ulf's work [1] [2].
This patch series can keep rtsx_usb suspended, to save ~0.5W on Intel
platforms and ~1.5W on AMD platforms.
[1] https://patchwork.kernel.org/patch/10440583/
[2] https://patchwork.kernel.org/patch/10445725/
Kai-Heng Feng (4):
misc: rtsx_usb: Use USB rem
Although rtsx_usb doesn't support card removal detection, card insertion
will resume rtsx_usb by USB remote wakeup signaling.
When rtsx_usb gets resumed, also resumes its child devices,
rtsx_usb_sdmmc and rtsx_usb_ms, to notify them there's a card in its
slot.
Signed-off-by: Kai-Heng Feng
---
d
We can use MEMSTICK_POWER_{ON,OFF} along with pm_runtime_{get,put}
helpers to let memstick host support runtime pm.
There's a small window between memstick_detect_change() and its queued
work, memstick_check(). In this window the rpm count may go down to zero
before the memstick host powers on, so
In order to let host's parent device, rtsx_usb, to use USB remote wake
up signaling to do card detection, it needs to be suspended. Hence it's
necessary to add runtime PM support for the memstick host.
To keep memstick host stays suspended when it's not in use, convert the
card detection function
Use ms_dev() helper for consistency.
Signed-off-by: Kai-Heng Feng
---
drivers/memstick/host/rtsx_usb_ms.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/memstick/host/rtsx_usb_ms.c
b/drivers/memstick/host/rtsx_usb_ms.c
index 4f64563df7de..cd12f3d1c088 100644
-
I noticed these independent Renesas drivers have needless dummy runtime
PM callbacks. I don't have the HW so only build tested.
Patches can be applied independently to their own subsystems. I wanted to
send them together if some of them gets Tested-by or sees a regression.
Jarkko Nikula (3):
i2
Platform drivers don't need dummy runtime PM callbacks that just return
success in order to have runtime PM happening. This has changed since
following commits:
05aa55dddb9e ("PM / Runtime: Lenient generic runtime pm callbacks")
543f2503a956 ("PM / platform_bus: Allow runtime PM by default")
8b313
Platform drivers don't need dummy runtime PM callbacks that just return
success and non-NULL pm pointer in their struct device_driver in order
to have runtime PM happening. This has changed since following commits:
05aa55dddb9e ("PM / Runtime: Lenient generic runtime pm callbacks")
543f2503a956 ("
Platform drivers don't need dummy runtime PM callbacks that just return
success in order to have runtime PM happening. This has changed since
following commits:
05aa55dddb9e ("PM / Runtime: Lenient generic runtime pm callbacks")
543f2503a956 ("PM / platform_bus: Allow runtime PM by default")
8b313
On Wed, Oct 24, 2018 at 04:51:31PM +0300, Jarkko Nikula wrote:
> I noticed these independent Renesas drivers have needless dummy runtime
> PM callbacks. I don't have the HW so only build tested.
>
> Patches can be applied independently to their own subsystems. I wanted to
> send them together if s
This will prepare the device connection API for connections
described in firmware.
Signed-off-by: Heikki Krogerus
---
include/linux/device.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index 90224e75ade4..a964a0d614fa 100644
--- a/inc
When the connections are defined in firmware, struct
device_connection will have the fwnode member pointing to
the device node (struct fwnode_handle) of the requested
device, and the endpoint will not be used at all in that
case.
Signed-off-by: Heikki Krogerus
---
drivers/usb/common/roles.c | 16
When the connections are defined in firmware, struct
device_connection will have the fwnode member pointing to
the device node (struct fwnode_handle) of the requested
device, and the endpoint will not be used at all in that
case.
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/mux.c | 19 ++
Hi,
I'm only presenting my idea with these how I think we should be able
to deal with graphs in the API, so these are completely untested, and
obviously I can't say for certain if the idea works or not.
I will try to test these using custom ACPI tables, but of course these
should be tested on DT
When the connections are defined in firmware, struct
device_connection will have the fwnode member pointing to
the device node (struct fwnode_handle) of the requested
device, and the endpoint will not be used at all in that
case.
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/class.c | 19
If connections between devices are described in OF graph or
ACPI device graph, we can find them by using the
fwnode_graph_*() functions.
Signed-off-by: Heikki Krogerus
---
drivers/base/devcon.c | 48 ---
1 file changed, 45 insertions(+), 3 deletions(-)
di
On 10/24/18 8:05 AM, Heikki Krogerus wrote:
> This will prepare the device connection API for connections
> described in firmware.
>
> Signed-off-by: Heikki Krogerus
> ---
> include/linux/device.h | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/include/linux/device.h b/include/li
Hello!
On 10/24/2018 06:05 PM, Heikki Krogerus wrote:
> When the connections are defined in firmware, struct
> device_connection will have the fwnode member pointing to
> the device node (struct fwnode_handle) of the requested
> device, and the endpoint will not be used at all in that
> case.
>
> At least the I2C driver part of this was on my todo list as well (just a
> bit lower :/). I wanted to find out why they have been there in the
> first place. Do you know if such callbacks were needed "back in the
> days"?
I see now that you referenced the relevant commits in the patch
descripti
Hi Jarkko,
> From: Jarkko Nikula, Sent: Wednesday, October 24, 2018 10:52 PM
>
> Platform drivers don't need dummy runtime PM callbacks that just return
> success in order to have runtime PM happening. This has changed since
> following commits:
>
> 05aa55dddb9e ("PM / Runtime: Lenient generic r
41 matches
Mail list logo
