Hi and thanks for your review!
On 13 April 2016 at 15:54, Kishon Vijay Abraham I wrote:
> On Monday 11 April 2016 03:13 PM, Rafał Miłecki wrote:
>> +Example:
>> + usb2-phy {
>> + compatible = "brcm,ns-usb2-phy";
>> + reg = <0x1800c000 0x1000>;
>> + reg-name
Simon Wood wrote:
> The card shows up under '/proc/asound/cards', but only as Midi.
Apparently, there is no PCM device. This driver creates a special
hardware-dependent device which is intended to be used with the
Jack driver "usb_stream".
It might be possible to use the ALSA "usb_stream" plugin:
On Wed, 2016-04-13 at 14:33 -0700, Greg KH wrote:
> But larger issue, no new module parameters for things like this. No one
> will use them and they aren't device or bus specific. It's a huge
> hammer that isn't nice to use.
But this is a valuable debug tool.
Regards
Ol
Hi,
changbin...@intel.com writes:
> From: "Du, Changbin"
>
> For DWC3 USB controller, the Global Debug Queue/FIFO Space Available
> Register(GDBGFIFOSPACE) can be used to dump FIFO/Queue available space.
> This can be used to check some special issues, like whether data is
> successfully copied
On Wed, 2016-04-13 at 15:11 -0700, Greg KH wrote:
> On Wed, Apr 13, 2016 at 02:37:35PM -0700, Matthew Giassa wrote:
> > Thank you for the feedback Greg. This is my first attempt to submit a
> > kernel patch.
> >
> > Is there a better approach to this? The only other option at my disposal
> > is to
Hi,
> From: Roger Quadros
> Sent: Monday, April 11, 2016 7:55 PM
>
> On 08/04/16 14:22, Yoshihiro Shimoda wrote:
> > Hi,
> >
> >> From: Roger Quadros
> >> Sent: Thursday, April 07, 2016 8:45 PM
> >>
> >> Hi,
> >>
> >> On 07/04/16 11:52, Yoshihiro Shimoda wrote:
> >>> Hi,
> >>>
> From: Roger
Oliver Neukum writes:
> On Wed, 2016-04-13 at 14:33 -0700, Greg KH wrote:
>
>> But larger issue, no new module parameters for things like this. No one
>> will use them and they aren't device or bus specific. It's a huge
>> hammer that isn't nice to use.
>
> But this is a valuable debug tool.
Ev
On Thu, 2016-04-14 at 10:53 +0200, Bjørn Mork wrote:
> Even more valuable when you make it device or bus specific. I don't see
> Greg arguing against a knob to turn off LPM. Only the slegde hammer
> operated master switch implementation :)
We do have nousb and autosuspend=-1
And it is easy to e
Hi,
> From: Sudip Mukherjee
> Sent: Saturday, April 09, 2016 12:05 AM
>
> The return type of usbhsp_setup_pipecfg() was u16 but it was returning
> a negative value (-EINVAL). Instead lets return a pointer to u16 which
> will hold the value to be returned or in case of error, return the
> error co
Hi,
Yoshihiro Shimoda writes:
>> From: Sudip Mukherjee
>> Sent: Saturday, April 09, 2016 12:05 AM
>>
>> The return type of usbhsp_setup_pipecfg() was u16 but it was returning
>> a negative value (-EINVAL). Instead lets return a pointer to u16 which
>> will hold the value to be returned or in ca
On 14/04/16 11:36, Yoshihiro Shimoda wrote:
> Hi,
>
>> From: Roger Quadros
>> Sent: Monday, April 11, 2016 7:55 PM
>>
>> On 08/04/16 14:22, Yoshihiro Shimoda wrote:
>>> Hi,
>>>
From: Roger Quadros
Sent: Thursday, April 07, 2016 8:45 PM
Hi,
On 07/04/16 11:52, Yoshihiro
Hi,
> From: Roger Quadros
> Sent: Thursday, April 14, 2016 8:00 PM
>
> On 14/04/16 11:36, Yoshihiro Shimoda wrote:
> > Hi,
> >
< snip >
> > diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
> > index e3d0161..8b74715 100644
> > --- a/drivers/usb/common/common.c
> > +++ b/driv
Hi, Balbi.
Feel free to change it, I may not have enough time on this currently.
"per-endpoint directory" is great idea, then we do not need find out
wanted info from one big file, but just go to specific dir.
Btw, I'd mention that not all out ep has a rx fifo. So in my original patch,
not all FI
Hi,
"Du, Changbin" writes:
> Hi, Balbi.
>
> Feel free to change it, I may not have enough time on this currently.
> "per-endpoint directory" is great idea, then we do not need find out
> wanted info from one big file, but just go to specific dir.
that was the idea, glad you liked it ;-)
> Btw
On 14/04/16 14:15, Yoshihiro Shimoda wrote:
> Hi,
>
>> From: Roger Quadros
>> Sent: Thursday, April 14, 2016 8:00 PM
>>
>> On 14/04/16 11:36, Yoshihiro Shimoda wrote:
>>> Hi,
>>>
> < snip >
>>> diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
>>> index e3d0161..8b74715 100644
> > At last, comparing with the FIFO/Queue info, I think software transfer
> > Requests list, TRBs info, EVENTs history are much more useful for
> debugging
> > the driver. If you can also add these info to each EP folder, that is
> > awesome!
> > :)
>
> I'll think about adding these but for the
Hi,
"Du, Changbin" writes:
>> > At last, comparing with the FIFO/Queue info, I think software transfer
>> > Requests list, TRBs info, EVENTs history are much more useful for
>> debugging
>> > the driver. If you can also add these info to each EP folder, that is
>> > awesome!
>> > :)
>>
>> I'll
> Hi,
>
> "Du, Changbin" writes:
> >> > At last, comparing with the FIFO/Queue info, I think software transfer
> >> > Requests list, TRBs info, EVENTs history are much more useful for
> >> debugging
> >> > the driver. If you can also add these info to each EP folder, that is
> awesome!
> >> > :)
On 14.04.2016 01:36, Greg KH wrote:
On Wed, Apr 13, 2016 at 03:21:09PM -0700, Matthew Giassa wrote:
The devices support LPM and are USB3.0 certified, and they work fine in
Windows using the same Intel 8/9/10 Series USB host controllers, along
with Renesas and Fresco controllers. On Linux the dev
On 14.04.2016 01:42, Matthew Giassa wrote:
Mathias provided me with some usb device calls I could use to resolve
this in software (pm_runtime_get_xxx(), pm_runtime_put()), but I'm not
familiar with the API, so I'd need some help figure out how to get the
`struct device*' handle for my current dev
Hi,
On Thursday 14 April 2016 02:21 AM, David Lechner wrote:
> On 04/01/2016 08:16 AM, Kishon Vijay Abraham I wrote:
>
>>> +EXPORT_SYMBOL_GPL(da8xx_usb20_phy_set_mode);
>>
>> Don't prefer export symbols from PHY driver. That'll create unnecessary
>> dependencies between the controller and the PHY
Hi,
On Thursday 14 April 2016 01:37 AM, David Lechner wrote:
> On 04/13/2016 08:20 AM, Kishon Vijay Abraham I wrote:
>>
>> Don't prefer export symbols from PHY driver. That'll create unnecessary
>> dependencies between the controller and the PHY.
>>
>> To see how to fix it, please see my comment f
dwc3 is in dual-role, with "synopsys,dwc3" specified in DT.
When xhci is probed, initiated from dwc3/host.c (not DT), we get :
xhci-hcd: probe of xhci-hcd.7.auto failed with error -5
This -EIO error originated from inside dma_set_mask() down in
include/asm-generic/dma-mapping-common.h
If "generi
Hi David,
David Fisher writes:
> dwc3 is in dual-role, with "synopsys,dwc3" specified in DT.
>
> When xhci is probed, initiated from dwc3/host.c (not DT), we get :
> xhci-hcd: probe of xhci-hcd.7.auto failed with error -5
> This -EIO error originated from inside dma_set_mask() down in
> include
On Wed, 13 Apr 2016, Matthew Giassa wrote:
> Mathias provided me with some usb device calls I could use to resolve
> this in software (pm_runtime_get_xxx(), pm_runtime_put()), but I'm not
> familiar with the API, so I'd need some help figure out how to get the
> `struct device*' handle for my curr
On Thu, 14 Apr 2016, Felipe Balbi wrote:
> >> --- a/drivers/usb/storage/scsiglue.c
> >> +++ b/drivers/usb/storage/scsiglue.c
> >> @@ -127,6 +127,11 @@ static int slave_configure(struct scsi_device *sdev)
> >>if (queue_max_hw_sectors(sdev->request_queue) > max_sectors)
> >>
On Thu, 14 Apr 2016, Oliver Neukum wrote:
> On Wed, 2016-04-13 at 15:11 -0700, Greg KH wrote:
> > On Wed, Apr 13, 2016 at 02:37:35PM -0700, Matthew Giassa wrote:
> > > Thank you for the feedback Greg. This is my first attempt to submit a
> > > kernel patch.
> > >
> > > Is there a better approach
On Thu, 14 Apr 2016, Mathias Nyman wrote:
> On 14.04.2016 01:36, Greg KH wrote:
> > On Wed, Apr 13, 2016 at 03:21:09PM -0700, Matthew Giassa wrote:
> >> The devices support LPM and are USB3.0 certified, and they work fine in
> >> Windows using the same Intel 8/9/10 Series USB host controllers, alo
Calling the ki_complete() callback will free the underlying data structure.
Make sure that it is no longer accessed beyond that point, otherwise
undefined behaviour might occur.
Fixes: 2e4c7553cd6f ("usb: gadget: f_fs: add aio support")
Signed-off-by: Lars-Peter Clausen
---
drivers/usb/gadget/fu
Hi Alan,
You are correct: the software claims and releases certain interfaces
frequently.
The cameras have one interface with a single BULK IN endpoint, which is
used to request image data from the camera via asynchronous bulk reads
via libusb. The interface is claimed for the duration of media
Hi Mathias,
Applying the patch you provided did not have any impact, and the issue
persists with it in place.
Thank you.
Matthew Giassa, MASc, BASc, EIT
Security and Embedded Systems Specialist
linkedin: https://ca.linkedin.com/in/gias
I should also note that these "control" r/w calls are made very
frequently. A thread is spawned for each camera that periodically polls
for things like exposure levels, average brightness, etc, to update a
metrics cache and UI display for said metrics.
=
On Thu, 14 Apr 2016, Matthew Giassa wrote:
> Hi Alan,
>
> You are correct: the software claims and releases certain interfaces
> frequently.
How frequently? The usbmon log you attached to the Bugzilla report
shows it happening at intervals of approximately 20-40 ms (sometimes
longer) -- and of
On Thursday 14 April 2016 04:25 PM, Felipe Balbi wrote:
Hi,
Yoshihiro Shimoda writes:
From: Sudip Mukherjee
Sent: Saturday, April 09, 2016 12:05 AM
The return type of usbhsp_setup_pipecfg() was u16 but it was returning
a negative value (-EINVAL). Instead lets return a pointer to u16 which
wi
On Thu, 14 Apr 2016, Matthew Giassa wrote:
> I should also note that these "control" r/w calls are made very
> frequently. A thread is spawned for each camera that periodically polls
> for things like exposure levels, average brightness, etc, to update a
> metrics cache and UI display for said met
Replying in-line:
> > You are correct: the software claims and releases certain interfaces
> > frequently.
>
> How frequently? The usbmon log you attached to the Bugzilla report
> shows it happening at intervals of approximately 20-40 ms (sometimes
> longer) -- and often with no messages sent i
I like that approach, and considered going that route. The problem is
that it would either require my interface library to be re-written as a
system service/daemon/resmgr, or I'd have to re-write a substantial
portion of it to check for a singleton instance of the library at load
time, and it seems
On Thu, April 14, 2016 1:35 am, Clemens Ladisch wrote:
> Simon Wood wrote:
>
>> The card shows up under '/proc/asound/cards', but only as Midi.
>>
>
> Apparently, there is no PCM device. This driver creates a special
> hardware-dependent device which is intended to be used with the Jack driver
> "u
This is a sincere question, and not an attempt at being snide, but from
a userspace perspective, should the frequency of claiming/releasing an
interface really matter? There's nothing in the libusb documentation
advising against it, and the docs also state it must be used before
performing I/O:
Hello,
I compiled and installed linux-4.6-rc3 on my beagle bone black and
noticed that when I unload a gadget using f_sourcesink (namely
g_zero), a kernel panic occurs:
[ 12.531504] Unable to handle kernel NULL pointer dereference at virtual
address 0005
[ 12.540100] pgd = de6a4000
[ 12.
Some functions, such as f_sourcesink, rely on an endpoint's desc
field during their requests' complete() callback, so clear it only
_after_ nuking all requests to avoid NULL pointer dereference.
Signed-off-by: Tal Shorer
---
drivers/usb/musb/musb_gadget.c | 6 +++---
1 file changed, 3 insertions
On Wed, Apr 13, 2016 at 05:44:01PM -0500, dingu...@opensource.altera.com wrote:
> From: Dinh Nguyen
>
> Document the optional 'resets' and 'reset-names' property for the DWC2 usb
> core.
>
> Signed-off-by: Dinh Nguyen
> ---
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rutland
> Cc: Ian Camp
On Thu, 14 Apr 2016, Matthew Giassa wrote:
> Replying in-line:
>
> > > You are correct: the software claims and releases certain interfaces
> > > frequently.
> >
> > How frequently? The usbmon log you attached to the Bugzilla report
> > shows it happening at intervals of approximately 20-40 ms
Simon Wood wrote:
> On Thu, April 14, 2016 1:35 am, Clemens Ladisch wrote:
>> Simon Wood wrote:
>>> The card shows up under '/proc/asound/cards', but only as Midi.
>>
>> Apparently, there is no PCM device. This driver creates a special
>> hardware-dependent device which is intended to be used with
On Thu, 14 Apr 2016, Alan Stern wrote:
> On Thu, 14 Apr 2016, Matthew Giassa wrote:
>
> > Replying in-line:
> >
> > > > You are correct: the software claims and releases certain interfaces
> > > > frequently.
> > >
> > > How frequently? The usbmon log you attached to the Bugzilla report
> > >
I've prepared some updated results.
If I use an older, USB2.0 model of one of these cameras, it has a single
endpoint, with a BULK IN and a BULK OUT endpoint. These interfaces are
used to read/write config data, registers, etc, and the sole BULK IN
interface is also used to acquire streaming image
On 4/13/2016 7:04 PM, Arnd Bergmann wrote:
> On Thursday 14 April 2016, dingu...@opensource.altera.com wrote:
>> @@ -337,6 +338,17 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg
>> *hsotg)
>> {
>> int i, ret;
>>
>> + hsotg->reset = devm_reset_control_get(hsotg->dev, "dwc2")
Including mach/* is frowned upon in device drivers, so get rid of it.
This replaces usb20_clk and code that pokes CFGCHIP2 with a proper phy
driver.
Signed-off-by: David Lechner
Acked-by: Alan Stern
---
v4 changes: no change
drivers/usb/host/Kconfig | 1 +
drivers/usb/host/ohci-da8xx
Use the new phy-da8xx-usb driver to take the place of the mach code that
pokes CFGCHIP2 in the da8xx musb glue driver. This unbreaks the driver.
Signed-off-by: David Lechner
---
v4 changes:
* using new phy->ops->get_mode()
drivers/usb/musb/Kconfig | 2 +-
drivers/usb/musb/da8xx.c | 141 +++
The initial use for this is for PHYs that have a mode related to USB OTG.
There are several SoCs (e.g. TI OMAP and DA8xx) that have a mode setting
in the USB PHY to override OTG VBUS and ID signals.
Of course, the enum can be expaned in the future to include modes for
other types of PHYs as well.
The "da8xx USB clocks" patch series was growing a bit too big, so on the advice
of Sekhar Nori, I am splitting it into two parts. This part contains everything
in drivers/ and the other part will contain everything in arch/arm/mach-davinci.
This patch series will apply and build on its own. It jus
Simplify things a bit by using devm functions where possible.
Signed-off-by: David Lechner
---
v4 changes: no change
drivers/usb/musb/da8xx.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index b03d
Device tree binding for new phy-da8xx-usb driver.
Signed-off-by: David Lechner
Acked-by: Rob Herring
---
v4 changes:
* swapped order of usb20 and usb11 to be in logical order of reg address.
.../devicetree/bindings/phy/phy-da8xx-usb.txt | 40 ++
1 file changed, 40 in
This is a new phy driver for the SoC USB controllers on the TI DA8xx
family of microcontrollers. The USB 1.1 PHY is just a simple on/off.
The USB 2.0 PHY also allows overriding the VBUS and ID pins.
Signed-off-by: David Lechner
---
v4 changes:
* Using phy->ops->get_mode() instead of exporting s
We will be using a generic syscon device for the TI DA8XX SoC CFGCHIPx
retisters. This will be used by a number of planned drivers including a
new USB PHY driver and common clock framework drivers.
The same defines are removed from the platform_data header file since they
are now redundant and the
The CFGCHIP registers are used by a number of devices, so using a syscon
device to share them. The first consumer of this will by the phy-da8xx-usb
driver.
Signed-off-by: David Lechner
---
v4 changes: none
arch/arm/mach-davinci/board-da830-evm.c | 4
arch/arm/mach-davinci/board-da85
Up to this point, the USB phy clock configuration was handled manually in
the board files and in the usb drivers. This adds proper clocks so that
the usb drivers can use clk_get and clk_enable and not have to worry about
the details. Also, the related code is removed from the board files and
replac
Add a node for the new usb phy driver.
Signed-off-by: David Lechner
---
v4 changes: none
arch/arm/boot/dts/da850.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index e56c554..2c60751 100644
--- a/arch/arm/boot/dts/da85
Add a syscon node for the SoC CFGCHIPn registers. This is needed for
the new usb phy driver.
Signed-off-by: David Lechner
---
v4 changes: none
arch/arm/boot/dts/da850.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index
Here is the second half of v3 "da8xx UBS clocks" that just includes the
arch/arm/mach-davinci/ portion. There were no comments on these patches, so
they are mostly unchanged other than fixing on strict checkpatch complaint.
This series also requires include/linux/mfd/da8xx-cfgchip.h from the "da8x
There is now a proper phy driver for the DA8xx SoC USB PHY. This adds the
platform device declarations needed to use it.
Signed-off-by: David Lechner
---
v4 changes: none
arch/arm/mach-davinci/board-da830-evm.c | 28 +---
arch/arm/mach-davinci/board-omapl138-hawk.c
Hello.
On 04/14/2016 10:44 PM, David Lechner wrote:
Add a node for the new usb phy driver.
Signed-off-by: David Lechner
---
v4 changes: none
arch/arm/boot/dts/da850.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
On Tue, Mar 8, 2016 at 8:59 AM, Timur Tabi wrote:
>> + /* Try setting the coherent_dma_mask to 64 bits, then try 32 bits
>> */
>> + ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
>> + if (ret) {
>> + ret = dma_set_mask_and_coherent(&pdev->dev,
>> DMA
On Thu, 14 Apr 2016, Matthew Giassa wrote:
> This patch works. Thank you Alan.
>
> What should we do next if I want to push it upstream? Do you propose and
> sign off on it, and I mark it as reviewed?
I don't know about that patch. Other people may object to disabling
LPM for all Point Grey Res
On 04/14/2016 01:23 PM, John Youn wrote:
> On 4/13/2016 7:04 PM, Arnd Bergmann wrote:
>> On Thursday 14 April 2016, dingu...@opensource.altera.com wrote:
>>> @@ -337,6 +338,17 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg
>>> *hsotg)
>>> {
>>> int i, ret;
>>>
>>> + hsotg->
On Thu, 2016-04-14 at 10:38 -0400, Alan Stern wrote:
> > So we have quirk for it. The ability to trigger this quirk the hard
> way
> > would be useful for debugging. Thus I believe that this patch is a
> good
> > idea.
>
> If this is for debugging then maybe it belongs in debugfs. Doing it
> tha
From: Dinh Nguyen
Allow for platforms that have a reset controller driver in place to bring
the USB IP out of reset.
Signed-off-by: Dinh Nguyen
---
v5: updated error conditions for not finding the reset property
v4: use dev_dbg() if not a -EPROBE_DEFER
v3: fix compile error
v2: move to lowlevel
From: Bjørn Mork
Date: Tue, 12 Apr 2016 16:11:12 +0200
> We now have a positive report of another Huawei device needing
> this quirk: The ME906s-158 (12d1:15c1). This is an m.2 form
> factor modem with no obvious relationship to the E3372 (12d1:157d)
> we already have a quirk entry for. This is
Hi,
On Wed, Apr 13, 2016 at 4:41 PM, Johannes Thumshirn wrote:
> Hi Sergey, Xiong,
>
> Can you try below patch?
This survives modprobe -r scsi_debug.
>
> On Montag, 11. April 2016 18:01:47 CEST Sergey Senozhatsky wrote:
>> Hello,
>>
>> commit 7b106f2de6938c31ce5e9c86bc70ad3904666b96
>> Author:
We have more use cases need to consider for vbus/id handler, below are
current use cases we know now:
- The vbus/id value can be read from external connectors, eg, gpio
- The vbus/id value can be read from register OTGSC
- The vbus is always on
- There is no ID pin, but need to switch role through
For some platforms, the vbus status doesn't be known by system at
device mode. So, there is no way to trigger pulling dp up. We add
a platform flag CI_HDRC_DP_ALWAYS_PULLUP to cover this situation.
With this flag set, the dp will be pulled up during the driver probe.
Signed-off-by: Peter Chen
Cc:
Hi,
On Wed, Apr 13, 2016 at 11:14 PM, James Bottomley
wrote:
> On Wed, 2016-04-13 at 10:41 +0200, Johannes Thumshirn wrote:
>> Hi Sergey, Xiong,
>>
>> Can you try below patch?
>>
>> On Montag, 11. April 2016 18:01:47 CEST Sergey Senozhatsky wrote:
>> > Hello,
>> >
>> > commit 7b106f2de6938c31ce5
72 matches
Mail list logo
