RE: ARM juno R2 board USB Issue (EHCI probe failed)

2016-09-27 Thread Sajjan, Vikas C 
Hi All,

-Original Message-
From: Robin Murphy [mailto:robin.mur...@arm.com] 
Sent: Tuesday, September 27, 2016 9:53 PM
To: Hanjun Guo ; Sudeep Holla ; 
Sajjan, Vikas C ; Vikas Sajjan 
; linux-usb@vger.kernel.org; 
linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org
Cc: mark.rutl...@arm.com; lorenzo.pieral...@arm.com
Subject: Re: ARM juno R2 board USB Issue (EHCI probe failed)

On 27/09/16 17:13, Hanjun Guo wrote:
> On 09/27/2016 05:07 PM, Sudeep Holla wrote:
>>
>>
>> On 27/09/16 09:55, Sajjan, Vikas C wrote:
>>> Hi Sudeep,
>>>
>>> -Original Message-
>>> From: Sudeep Holla [mailto:sudeep.ho...@arm.com]
>>> Sent: Tuesday, September 27, 2016 2:21 PM
>>> To: Vikas Sajjan ; 
>>> linux-usb@vger.kernel.org; linux-arm-ker...@lists.infradead.org; 
>>> linux-a...@vger.kernel.org
>>> Cc: Sudeep Holla ; mark.rutl...@arm.com; 
>>> lorenzo.pieral...@arm.com; Sajjan, Vikas C 
>>> 
>>> Subject: Re: ARM juno R2 board USB Issue (EHCI probe failed)
>>>
>>> Hi Vikas,
>>>
>>> On 27/09/16 09:14, Vikas Sajjan wrote:
 Adding USB mailing list.


 On Tue, Sep 27, 2016 at 12:33 PM, Sajjan, Vikas C 
  wrote:
> Hi All,
>
> I working on ARM juno R2 board, with latest kernel 4.8.rc7 and I 
> get below USB EHCI probe error while booting with acpi=force.
>
>>>
>>> Are you using the latest UEFI EDK2 ?
>>> No, I am still using the UEFI binary which came as part of the Juno 
>>> board.
>>>
>>>
> [1.223662] VFIO - User Level meta-driver version: 0.3
> [1.229335] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI)
> Driver
> [1.235882] ehci-pci: EHCI PCI platform driver
> [1.240359] ehci-platform: EHCI generic platform driver
> [1.245619] ehci-platform ARMH0D20:00: Error: DMA mask
> configuration failed
> [1.272491] ehci-platform: probe of ARMH0D20:00 failed with
> error -5
> [1.278876] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> [1.285071] ohci-pci: OHCI PCI platform driver
> [1.289548] ohci-platform: OHCI generic platform driver
> [1.294884] usbcore: registered new interface driver usb-storage
> [1.301231] mousedev: PS/2 mouse device common for all mice
> [1.307197] rtc-efi rtc-efi: rtc core: registered rtc-efi as rtc0
>
> But this error goes off, if I don't force ACPI booting, i.e., if I 
> remove acpi=force from kernel command line , USB is detected  and 
> my RFS which is in the usb drive, gets mounted successfully.
>
>>>
>>> As I mentioned in private, I do get the same error if I drop _CCA in 
>>> USB object of ACPI DSDT. Can you give it a spin with latest UEFI ?
>>>
>>> Sure, will try with latest UEFI.
>>>
>>
>> I bet that's 8-12 months old. It puts the banner during boot with the 
>> build date. You can try to follow [1] or access it from [2]
> 
> Agree.
> 
> D03 is using the same IP (EHCI) and the USB works fine with _CCA in 
> the device node.

_CCA is mandatory on arm64 (see CONFIG_ACPI_CCA_REQUIRED). Any devices without 
it are going to end up with the dummy DMA ops which intentionally fail if a 
driver tries to use them - i.e. the error seen above is by design.

Thank you for the clarification.

Thanks and Regards
Vikas Sajjan

Robin.

> 
> Thanks
> Hanjun
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] Net Driver: Add Cypress GX3 VID=04b4 PID=3610.

2016-09-27 Thread David Miller 
From: 
Date: Tue, 27 Sep 2016 09:57:50 -0600

> From: Chris Roth 
> 
> From Allan Chou 
> From: Chris Roth 

Three From lines, it's actually quite amazing how you were
able to achieve this.

Please take some time, and carefully craft your patch emails but don't
send them to the list.

Instead, email yourself, and look at what you receive.

Do not post this patch to the list until the test emails you send to
yourself look correct.

Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 0/8] power: add power sequence library

2016-09-27 Thread Maciej S. Szmigiero 
On 20.09.2016 05:36, Peter Chen wrote:
> Hi all,
> 
> This is a follow-up for my last power sequence framework patch set [1].
> According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> power sequence instances will be added at postcore_initcall, the match
> criteria is compatible string first, if the compatible string is not
> matched between dts and library, it will try to use generic power sequence.
>
> The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> if only one power sequence instance is needed, for more power sequences
> are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub 
> driver).
> 
> In future, if there are special power sequence requirements, the special
> power sequence library can be created.
> 
> This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> two hot-plug devices to simulate this use case, the related binding
> change is updated at patch [1/6], The udoo board changes were tested
> using my last power sequence patch set.[3]
> 
> Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> need to power on itself before it can be found by ULPI bus.
> 
> [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> [3] http://www.spinics.net/lists/linux-usb/msg142815.html

Just tested this patch set on UDOO board again to make sure that it still
works after all changes done since it was last tested there and can confirm
that it does work correctly.

Maciej

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 0/8] power: add power sequence library

2016-09-27 Thread Peter Chen 
On Wed, Sep 28, 2016 at 01:30:17AM +0200, Maciej S. Szmigiero wrote:
> On 20.09.2016 05:36, Peter Chen wrote:
> > Hi all,
> > 
> > This is a follow-up for my last power sequence framework patch set [1].
> > According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> > power sequence instances will be added at postcore_initcall, the match
> > criteria is compatible string first, if the compatible string is not
> > matched between dts and library, it will try to use generic power sequence.
> >  
> > The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> > if only one power sequence instance is needed, for more power sequences
> > are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub 
> > driver).
> > 
> > In future, if there are special power sequence requirements, the special
> > power sequence library can be created.
> > 
> > This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> > two hot-plug devices to simulate this use case, the related binding
> > change is updated at patch [1/6], The udoo board changes were tested
> > using my last power sequence patch set.[3]
> > 
> > Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> > need to power on itself before it can be found by ULPI bus.
> > 
> > [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> > [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> > [3] http://www.spinics.net/lists/linux-usb/msg142815.html
> 
> Just tested this patch set on UDOO board again to make sure that it still
> works after all changes done since it was last tested there and can confirm
> that it does work correctly.
> 

Thanks, Maciej.

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

2016-09-27 Thread Pierre de Villemereuil 
Hi !

> run:
> sudo lspci -d :8c31 -vv

The command yields nothing, either on AC or battery, with a USB device plugged 
or not.

FYI, here's a 'blank' lspci:

00:00.0 Host bridge: Intel Corporation Skylake Host Bridge/DRAM Registers (rev 
08)
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 520 (rev 07)
00:04.0 Signal processing controller: Intel Corporation Skylake Processor 
Thermal Subsystem (rev 08)
00:13.0 Non-VGA unclassified device: Intel Corporation Device 9d35 (rev 21)
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI 
Controller (rev 21)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP 
Thermal subsystem (rev 21)
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP 
Serial IO I2C Controller #0 (rev 21)
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI 
#1 (rev 21)
00:17.0 SATA controller: Intel Corporation Sunrise Point-LP SATA Controller 
[AHCI mode] (rev 21)
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port 
#6 (rev f1)
00:1f.0 ISA bridge: Intel Corporation Sunrise Point-LP LPC Controller (rev 21)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)
01:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59)

> Did I understand correctly that there was nothing in dmesg if AC is
> unplugged when connecting a usb device? Not even with enhanced xhci
> debugging enabled?

Yes, that is correct.

> 
> Is there anything that looks suspicious in BIOS?
> An option that disables wake up events for usb ports? or disables
> usb ports, Energy saver support EuP/ErP?

No, the only thing in the BIOS regarding USB is a security feature allowing to 
disable it entirely and another one regarding "legacy USB" (which, as far as I 
understand concerns very old USB1 devices?).

Hope this helps,
Pierre
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] usb: add helper to extract bits 12:11 of wMaxPacketSize

2016-09-27 Thread Felipe Balbi 

Hi,

Bin Liu  writes:
>> > >> > Does this mean the issue of isoc high bandwidth transfer was fixed by
>> > >> > this patchset per your test?
>> > >> 
>> > >> No, I couldn't get g_webcam to work yet.
>> > >
>> > > In mainline, g_webcam is broken with DWC3. Also these two patches don't
>> > > fix the issue on v4.4.21.
>> > 
>> > care to send tracepoint output? Best if you could cherry pick my latest
>> > tracepoint changes so we have the best output possible.
>> > 
>> > I have also built a branch with v4.4.21 + all dwc3 patches (except for
>> > device properties and PCI stuff) which you could use for testing. If you
>> > run with that, then I can get proper trace output and I can try to
>> > figure out what's missing.
>> > 
>> > Branch is here:
>> > 
>> >   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
>> > usb/v4.4.21+dwc3
>> 
>> This branch does not generate the isoch traffic (on ep2in). ftrace
>> attached (dwc3-g_webcam-v4.4.21+tp.ftrace).
>> 
>> I also attached the ftrace log for v4.4.21 tag
>> (dwc3-g_webcam-v4.4.21.ftrace) for comparison, which has ep2in isoch
>> traffic, but only one transaction per SOF.
>
> Sorry, I didn't realize the ftrace file size is huge. Attached the
> tarball here.

looking at webcam.c, it'll set wMaxPacket correctly (to 0x1400) if you
pass streaming_maxpacket=3072. So that's one thing.

I'll look at this log with more detail tomorrow, though.

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: crash by cdc_acm driver in kernels 4.8-rc1/5

2016-09-27 Thread Wim Osterholt 
On Thu, Sep 22, 2016 at 04:40:50PM +0200, Oliver Neukum wrote:
> 
> dmesg -c
> echo 9 > /proc/sysrq-trigger
> modprobe cdc_acm
> echo "module cdc_acm +mpf" > /sys/kernel/debug/dynamic_debug/control
> 
> [plug your device in]
> 
> and provide the full output of dmesg after that.

After some experimenting I succeeded in grabbing it over the serial port.
The console was immedately frozen, but the serial port kept working:

[  407.859834] sysrq: SysRq : Changing Loglevel
[  407.908433] sysrq: Loglevel set to 9
[  407.980538] usbcore: registered new interface driver cdc_acm
[  408.044439] cdc_acm: USB Abstract Control Model driver for USB modems and 
ISDN adapters
[  410.480711] usb 6-1: new full-speed USB device number 2 using uhci_hcd
[  410.696717] usb 6-1: New USB device found, idVendor=0572, idProduct=1340
[  410.700739] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  410.704738] usb 6-1: Product: USB Modem
[  410.708735] usb 6-1: Manufacturer: Conexant
[  410.708738] usb 6-1: SerialNumber: 12345678
[  410.763492] cdc_acm:acm_probe: cdc_acm 6-1:1.0: interfaces are valid
[  410.763515] BUG: unable to handle kernel NULL pointer dereference at 0249
[  410.763522] IP: [] acm_probe+0x4ee/0xc8c [cdc_acm]
[  410.763524] *pde =  
[  410.763526] Oops:  [#1] SMP
[  410.763562] Modules linked in: cdc_acm nouveau video drm_kms_helper 
syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm agpgart i2c_algo_bit 
cfg80211 rfkill binfmt_misc snd_pcm_oss snd_mixer_oss fbcon bitblit softcursor 
font tileblit sr9700 dm9601 usb_storage usbnet snd_hda_codec_generic mii 
snd_hda_intel snd_hda_codec tg3 snd_hwdep ptp snd_hda_core pps_core snd_pcm 
gpio_ich libphy firmware_class pcspkr ohci_pci lpc_ich ppdev snd_timer mfd_core 
ohci_hcd snd uhci_hcd wmi parport_pc floppy ehci_pci soundcore parport ehci_hcd 
acpi_cpufreq button processor
[  410.763565] CPU: 0 PID: 429 Comm: kworker/0:1 Not tainted 4.8.0-rc8 #1
[  410.763567] Hardware name: Hewlett-Packard HP xw4300 Workstation/0A00h, BIOS 
786D3 v01.08 03/10/2006
[  410.763572] Workqueue: usb_hub_wq hub_event
[  410.763574] task: df523f00 task.stack: dec3
[  410.763576] EIP: 0060:[] EFLAGS: 00010202 CPU: 0
[  410.763579] EIP is at acm_probe+0x4ee/0xc8c [cdc_acm]
[  410.763581] EAX: 0246 EBX: decff000 ECX: e08e1854 EDX: 
[  410.763582] ESI: 0100 EDI:  EBP: dec31c18 ESP: dec31b80
[  410.763584]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[  410.763586] CR0: 80050033 CR2: 0249 CR3: 13edd000 CR4: 0690
[  410.763587] Stack:
[  410.763592]  3a20 3d01 000f df4a9d50   0010 
0040
[  410.763597]  0080 0246 df650ec0 dee42800 da86f470 0001 df7d2e80 
df7d2eb8
[  410.763601]  da86f400 dee42600 dee42800  da95f000 0004 0246 
dec31c00
[  410.763602] Call Trace:
[  410.763609]  [] ? __mutex_unlock_slowpath+0xf4/0xfc
[  410.763614]  [] ? usb_probe_interface+0x17b/0x1f6
[  410.763616]  [] ? usb_probe_interface+0x17b/0x1f6
[  410.763620]  [] ? driver_probe_device+0x17b/0x30e
[  410.763622]  [] ? driver_probe_device+0x17b/0x30e
[  410.763625]  [] ? bus_for_each_drv+0x59/0x68
[  410.763627]  [] ? bus_for_each_drv+0x59/0x68
[  410.763629]  [] ? __device_attach+0x91/0x105
[  410.763631]  [] ? driver_allows_async_probing+0x2f/0x2f
[  410.763634]  [] ? bus_probe_device+0x27/0x6b
[  410.763636]  [] ? bus_probe_device+0x27/0x6b
[  410.763638]  [] ? device_add+0x289/0x4be
[  410.763641]  [] ? usb_set_configuration+0x5a6/0x5e9
[  410.763643]  [] ? usb_set_configuration+0x5a6/0x5e9
[  410.763647]  [] ? generic_probe+0x3b/0x67
[  410.763649]  [] ? generic_probe+0x3b/0x67
[  410.763652]  [] ? usb_probe_device+0x49/0x62
[  410.763654]  [] ? usb_suspend+0xcd/0xcd
[  410.763656]  [] ? driver_probe_device+0x17b/0x30e
[  410.763658]  [] ? driver_probe_device+0x17b/0x30e
[  410.763661]  [] ? bus_for_each_drv+0x59/0x68
[  410.763663]  [] ? bus_for_each_drv+0x59/0x68
[  410.763665]  [] ? __device_attach+0x91/0x105
[  410.763667]  [] ? driver_allows_async_probing+0x2f/0x2f
[  410.763670]  [] ? bus_probe_device+0x27/0x6b
[  410.763672]  [] ? bus_probe_device+0x27/0x6b
[  410.763674]  [] ? device_add+0x289/0x4be
[  410.763677]  [] ? add_device_randomness+0x84/0x9c
[  410.763680]  [] ? usb_new_device+0x29d/0x3b5
[  410.763681]  [] ? usb_new_device+0x29d/0x3b5
[  410.763684]  [] ? hub_event+0xb32/0xed8
[  410.763686]  [] ? hub_event+0xb32/0xed8
[  410.763689]  [] ? usb_remote_wakeup+0x6f/0x7d
[  410.763693]  [] ? process_one_work+0x174/0x2bc
[  410.763695]  [] ? process_one_work+0x174/0x2bc
[  410.763698]  [] ? worker_thread+0x22c/0x2f6
[  410.763700]  [] ? rescuer_thread+0x23f/0x23f
[  410.763703]  [] ? kthread+0xa4/0xa9
[  410.763706]  [] ? ret_from_kernel_thread+0xe/0x24
[  410.763708]  [] ? kthread_create_on_node+0x101/0x101
[  410.763734] Code: 14 89 83 b4 04 00 00 8b 45 94 89 43 04 8b 45 ac 89 43 08 
8b 85 7c ff ff ff 89 83 c0 04 00 00 8b 45 a8 89 03 8b 45 c0 85 c0 74 0a <0f> b6 
40

Re: [PATCH] usb: Convert pr_warning to pr_warn

2016-09-27 Thread Robert Jarzmik 
Joe Perches  writes:

> Use the more common logging mechanism.
>
> Miscellanea:
>
> o Realign multiline statements
> o Coalesce format
>
> Signed-off-by: Joe Perches 
For pxa25x_udc.h:
Acked-by: Robert Jarzmik 

Cheers.

--
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ARM juno R2 board USB Issue (EHCI probe failed)

2016-09-27 Thread Robin Murphy 
On 27/09/16 17:13, Hanjun Guo wrote:
> On 09/27/2016 05:07 PM, Sudeep Holla wrote:
>>
>>
>> On 27/09/16 09:55, Sajjan, Vikas C wrote:
>>> Hi Sudeep,
>>>
>>> -Original Message-
>>> From: Sudeep Holla [mailto:sudeep.ho...@arm.com]
>>> Sent: Tuesday, September 27, 2016 2:21 PM
>>> To: Vikas Sajjan ; linux-usb@vger.kernel.org;
>>> linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org
>>> Cc: Sudeep Holla ; mark.rutl...@arm.com;
>>> lorenzo.pieral...@arm.com; Sajjan, Vikas C 
>>> Subject: Re: ARM juno R2 board USB Issue (EHCI probe failed)
>>>
>>> Hi Vikas,
>>>
>>> On 27/09/16 09:14, Vikas Sajjan wrote:
 Adding USB mailing list.


 On Tue, Sep 27, 2016 at 12:33 PM, Sajjan, Vikas C
  wrote:
> Hi All,
>
> I working on ARM juno R2 board, with latest kernel 4.8.rc7 and I get
> below USB EHCI probe error while booting with acpi=force.
>
>>>
>>> Are you using the latest UEFI EDK2 ?
>>> No, I am still using the UEFI binary which came as part of the Juno
>>> board.
>>>
>>>
> [1.223662] VFIO - User Level meta-driver version: 0.3
> [1.229335] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI)
> Driver
> [1.235882] ehci-pci: EHCI PCI platform driver
> [1.240359] ehci-platform: EHCI generic platform driver
> [1.245619] ehci-platform ARMH0D20:00: Error: DMA mask
> configuration failed
> [1.272491] ehci-platform: probe of ARMH0D20:00 failed with
> error -5
> [1.278876] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> [1.285071] ohci-pci: OHCI PCI platform driver
> [1.289548] ohci-platform: OHCI generic platform driver
> [1.294884] usbcore: registered new interface driver usb-storage
> [1.301231] mousedev: PS/2 mouse device common for all mice
> [1.307197] rtc-efi rtc-efi: rtc core: registered rtc-efi as rtc0
>
> But this error goes off, if I don't force ACPI booting, i.e., if I
> remove acpi=force from kernel command line , USB is detected  and my
> RFS which is in the usb drive, gets mounted successfully.
>
>>>
>>> As I mentioned in private, I do get the same error if I drop _CCA in
>>> USB object of ACPI DSDT. Can you give it a spin with latest UEFI ?
>>>
>>> Sure, will try with latest UEFI.
>>>
>>
>> I bet that's 8-12 months old. It puts the banner during boot with the
>> build date. You can try to follow [1] or access it from [2]
> 
> Agree.
> 
> D03 is using the same IP (EHCI) and the USB works fine with _CCA
> in the device node.

_CCA is mandatory on arm64 (see CONFIG_ACPI_CCA_REQUIRED). Any devices
without it are going to end up with the dummy DMA ops which
intentionally fail if a driver tries to use them - i.e. the error seen
above is by design.

Robin.

> 
> Thanks
> Hanjun
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: Convert pr_warning to pr_warn

2016-09-27 Thread Joe Perches 
Use the more common logging mechanism.

Miscellanea:

o Realign multiline statements
o Coalesce format

Signed-off-by: Joe Perches 
---
 drivers/usb/gadget/function/rndis.c |  9 -
 drivers/usb/gadget/function/u_serial.c  |  4 ++--
 drivers/usb/gadget/udc/at91_udc.h   |  2 +-
 drivers/usb/gadget/udc/atmel_usba_udc.c |  4 ++--
 drivers/usb/gadget/udc/fsl_usb2_udc.h   |  2 +-
 drivers/usb/gadget/udc/m66592-udc.c |  4 ++--
 drivers/usb/gadget/udc/omap_udc.h   |  2 +-
 drivers/usb/gadget/udc/pxa25x_udc.h |  2 +-
 drivers/usb/host/isp1362-hcd.c  | 27 ++-
 drivers/usb/isp1760/isp1760-if.c|  2 +-
 10 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/drivers/usb/gadget/function/rndis.c 
b/drivers/usb/gadget/function/rndis.c
index ab6ac1b74ac0..766c328c15c0 100644
--- a/drivers/usb/gadget/function/rndis.c
+++ b/drivers/usb/gadget/function/rndis.c
@@ -474,8 +474,7 @@ static int gen_ndis_query_resp(struct rndis_params *params, 
u32 OID, u8 *buf,
break;
 
default:
-   pr_warning("%s: query unknown OID 0x%08X\n",
-__func__, OID);
+   pr_warn("%s: query unknown OID 0x%08X\n", __func__, OID);
}
if (retval < 0)
length = 0;
@@ -546,8 +545,8 @@ static int gen_ndis_set_resp(struct rndis_params *params, 
u32 OID,
break;
 
default:
-   pr_warning("%s: set unknown OID 0x%08X, size %d\n",
-__func__, OID, buf_len);
+   pr_warn("%s: set unknown OID 0x%08X, size %d\n",
+   __func__, OID, buf_len);
}
 
return retval;
@@ -854,7 +853,7 @@ int rndis_msg_parser(struct rndis_params *params, u8 *buf)
 * In one case those messages seemed to relate to the host
 * suspending itself.
 */
-   pr_warning("%s: unknown RNDIS message 0x%08X len %d\n",
+   pr_warn("%s: unknown RNDIS message 0x%08X len %d\n",
__func__, MsgType, MsgLength);
print_hex_dump_bytes(__func__, DUMP_PREFIX_OFFSET,
 buf, MsgLength);
diff --git a/drivers/usb/gadget/function/u_serial.c 
b/drivers/usb/gadget/function/u_serial.c
index e0cd1e4c8892..62ec842874aa 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -622,8 +622,8 @@ static void gs_write_complete(struct usb_ep *ep, struct 
usb_request *req)
switch (req->status) {
default:
/* presumably a transient fault */
-   pr_warning("%s: unexpected %s status %d\n",
-   __func__, ep->name, req->status);
+   pr_warn("%s: unexpected %s status %d\n",
+   __func__, ep->name, req->status);
/* FALL THROUGH */
case 0:
/* normal completion */
diff --git a/drivers/usb/gadget/udc/at91_udc.h 
b/drivers/usb/gadget/udc/at91_udc.h
index 0a433e6b346b..9bbe72764f31 100644
--- a/drivers/usb/gadget/udc/at91_udc.h
+++ b/drivers/usb/gadget/udc/at91_udc.h
@@ -175,7 +175,7 @@ struct at91_request {
 #endif
 
 #define ERR(stuff...)  pr_err("udc: " stuff)
-#define WARNING(stuff...)  pr_warning("udc: " stuff)
+#define WARNING(stuff...)  pr_warn("udc: " stuff)
 #define INFO(stuff...) pr_info("udc: " stuff)
 #define DBG(stuff...)  pr_debug("udc: " stuff)
 
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
b/drivers/usb/gadget/udc/atmel_usba_udc.c
index 45bc997d0711..1ef7a9a9d7f5 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -1464,8 +1464,8 @@ static void usba_control_irq(struct usba_udc *udc, struct 
usba_ep *ep)
pkt_len = USBA_BFEXT(BYTE_COUNT, usba_ep_readl(ep, STA));
DBG(DBG_HW, "Packet length: %u\n", pkt_len);
if (pkt_len != sizeof(crq)) {
-   pr_warning("udc: Invalid packet length %u "
-   "(expected %zu)\n", pkt_len, sizeof(crq));
+   pr_warn("udc: Invalid packet length %u (expected 
%zu)\n",
+   pkt_len, sizeof(crq));
set_protocol_stall(udc, ep);
return;
}
diff --git a/drivers/usb/gadget/udc/fsl_usb2_udc.h 
b/drivers/usb/gadget/udc/fsl_usb2_udc.h
index 84715625b2b3..e92b8408b6f6 100644
--- a/drivers/usb/gadget/udc/fsl_usb2_udc.h
+++ b/drivers/usb/gadget/udc/fsl_usb2_udc.h
@@ -554,7 +554,7 @@ static void dump_msg(const char *label, const u8 * buf, 
unsigned int length)
 #endif
 
 #define ERR(stuff...)  pr_err("udc: " stuff)
-#define WARNING(stuff...)  pr_warning("udc: " stuff)
+#define WARNING(stuff...)  pr_warn("udc: " stuff)
 #define INFO(stuff...) pr_info("udc: " stuff)

Re: ARM juno R2 board USB Issue (EHCI probe failed)

2016-09-27 Thread Hanjun Guo 

On 09/27/2016 05:07 PM, Sudeep Holla wrote:



On 27/09/16 09:55, Sajjan, Vikas C wrote:

Hi Sudeep,

-Original Message-
From: Sudeep Holla [mailto:sudeep.ho...@arm.com]
Sent: Tuesday, September 27, 2016 2:21 PM
To: Vikas Sajjan ; linux-usb@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org
Cc: Sudeep Holla ; mark.rutl...@arm.com;
lorenzo.pieral...@arm.com; Sajjan, Vikas C 
Subject: Re: ARM juno R2 board USB Issue (EHCI probe failed)

Hi Vikas,

On 27/09/16 09:14, Vikas Sajjan wrote:

Adding USB mailing list.


On Tue, Sep 27, 2016 at 12:33 PM, Sajjan, Vikas C
 wrote:

Hi All,

I working on ARM juno R2 board, with latest kernel 4.8.rc7 and I get
below USB EHCI probe error while booting with acpi=force.



Are you using the latest UEFI EDK2 ?
No, I am still using the UEFI binary which came as part of the Juno
board.



[1.223662] VFIO - User Level meta-driver version: 0.3
[1.229335] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI)
Driver
[1.235882] ehci-pci: EHCI PCI platform driver
[1.240359] ehci-platform: EHCI generic platform driver
[1.245619] ehci-platform ARMH0D20:00: Error: DMA mask
configuration failed
[1.272491] ehci-platform: probe of ARMH0D20:00 failed with error -5
[1.278876] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[1.285071] ohci-pci: OHCI PCI platform driver
[1.289548] ohci-platform: OHCI generic platform driver
[1.294884] usbcore: registered new interface driver usb-storage
[1.301231] mousedev: PS/2 mouse device common for all mice
[1.307197] rtc-efi rtc-efi: rtc core: registered rtc-efi as rtc0

But this error goes off, if I don't force ACPI booting, i.e., if I
remove acpi=force from kernel command line , USB is detected  and my
RFS which is in the usb drive, gets mounted successfully.



As I mentioned in private, I do get the same error if I drop _CCA in
USB object of ACPI DSDT. Can you give it a spin with latest UEFI ?

Sure, will try with latest UEFI.



I bet that's 8-12 months old. It puts the banner during boot with the
build date. You can try to follow [1] or access it from [2]


Agree.

D03 is using the same IP (EHCI) and the USB works fine with _CCA
in the device node.

Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] Net Driver: Add Cypress GX3 VID=04b4 PID=3610.

2016-09-27 Thread chris.roth 
From: Chris Roth 

>From Allan Chou 
From: Chris Roth 

Add support for Cypress GX3 SuperSpeed to Gigabit Ethernet
Bridge Controller (Vendor=04b4 ProdID=3610).

Patch verified on x64 linux kernel 4.7.4 system with the
Kensington SD4600P USB-C Universal Dock with Power, which uses the
Cypress GX3 SuperSpeed to Gigabit Ethernet Bridge Controller.

A similar patch was signed-off and tested-by Allan Chou
 on 2015-12-01.

Allan verified his similar patch on x86 Linux kernel 4.1.6 system
with Cypress GX3 SuperSpeed to Gigabit Ethernet Bridge Controller.

Tested-by: Allan Chou 
Tested-by: Chris Roth 

Signed-off-by: Allan Chou 
Signed-off-by: Chris Roth 
---
 drivers/net/usb/ax88179_178a.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index e6338c1..8a6675d 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -1656,6 +1656,19 @@ static const struct driver_info ax88178a_info = {
.tx_fixup = ax88179_tx_fixup,
 };
 
+static const struct driver_info cypress_GX3_info = {
+   .description = "Cypress GX3 SuperSpeed to Gigabit Ethernet Controller",
+   .bind = ax88179_bind,
+   .unbind = ax88179_unbind,
+   .status = ax88179_status,
+   .link_reset = ax88179_link_reset,
+   .reset = ax88179_reset,
+   .stop = ax88179_stop,
+   .flags = FLAG_ETHER | FLAG_FRAMING_AX,
+   .rx_fixup = ax88179_rx_fixup,
+   .tx_fixup = ax88179_tx_fixup,
+};
+
 static const struct driver_info dlink_dub1312_info = {
.description = "D-Link DUB-1312 USB 3.0 to Gigabit Ethernet Adapter",
.bind = ax88179_bind,
@@ -1718,6 +1731,10 @@ static const struct usb_device_id products[] = {
USB_DEVICE(0x0b95, 0x178a),
.driver_info = (unsigned long)_info,
 }, {
+   /* Cypress GX3 SuperSpeed to Gigabit Ethernet Bridge Controller */
+   USB_DEVICE(0x04b4, 0x3610),
+   .driver_info = (unsigned long)_GX3_info,
+}, {
/* D-Link DUB-1312 USB 3.0 to Gigabit Ethernet Adapter */
USB_DEVICE(0x2001, 0x4a00),
.driver_info = (unsigned long)_dub1312_info,
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] Net Driver: Add Cypress GX3 VID=04b4 PID=3610.

2016-09-27 Thread Greg KH 
On Mon, Sep 26, 2016 at 03:56:59PM -0600, Chris Roth wrote:
> I'm not sure what I'm doing wrong:
> 
> I'm trying to get the from statement to read original author (Allan
> Chou) first, and then me (Chris Roth) second. I've used the following
> two commands:
> 
> git format-patch -o /tmp/ --subject-prefix="PATCH v2" --from="Allan
> Chou " HEAD^
> 
> and
> 
> git send-email --to linux-usb@vger.kernel.org --to
> net...@vger.kernel.org --to linux-ker...@vger.kernel.org --from="Allan
> Chou "
> /tmp/0001-Net-Driver-Add-Cypress-GX3-VID-04b4-PID-3610.patch
> 
> I thought that adding the --from portions to the git format-patch and
> git send-email commands would force the addition of Allan to the top
> of the patch, but it hasn't. Can anyone tell me specifically how I
> need to change these commands in order to get the desired result? Then
> I'll submit a PATCH v3.

Take the patch that you have, hand-edit it with your favorite editor to
have the correct headers and signed-off-by and other fields, and then
use git send-email without the --from line, and you should be fine.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] usb: add helper to extract bits 12:11 of wMaxPacketSize

2016-09-27 Thread yfw 



On 2016/9/27 23:12, Bin Liu wrote:

On Tue, Sep 27, 2016 at 11:02:54PM +0800, yfw wrote:



On 2016/9/27 23:00, Bin Liu wrote:

On Tue, Sep 27, 2016 at 10:53:54PM +0800, yfw wrote:

Hi,

On 2016/9/27 22:28, Bin Liu wrote:

On Tue, Sep 27, 2016 at 09:20:56AM -0500, Bin Liu wrote:

Felipe,

On Tue, Sep 27, 2016 at 10:18:26AM +0300, Felipe Balbi wrote:

[snip]


Does this mean the issue of isoc high bandwidth transfer was fixed by
this patchset per your test?


No, I couldn't get g_webcam to work yet.


In mainline, g_webcam is broken with DWC3. Also these two patches don't
fix the issue on v4.4.21.


care to send tracepoint output? Best if you could cherry pick my latest
tracepoint changes so we have the best output possible.

I have also built a branch with v4.4.21 + all dwc3 patches (except for
device properties and PCI stuff) which you could use for testing. If you
run with that, then I can get proper trace output and I can try to
figure out what's missing.

Branch is here:

git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git usb/v4.4.21+dwc3


This branch does not generate the isoch traffic (on ep2in). ftrace
attached (dwc3-g_webcam-v4.4.21+tp.ftrace).

I also attached the ftrace log for v4.4.21 tag
(dwc3-g_webcam-v4.4.21.ftrace) for comparison, which has ep2in isoch
traffic, but only one transaction per SOF.


Sorry, I didn't realize the ftrace file size is huge. Attached the
tarball here.
(dwc3-g_webcam-ftrace.tgz)

Regards,
-Bin.


>From the ftrace log:



irq/441-dwc3-769   [001] d..2   101.207679: dwc3_gadget: ep2in-isoc: req
ed971b00 dma ad9d2000 length 5120

5120 looks wrong to me. 5120 == 0x1400. There is an issue in uvc_video which
set the req_size according maxpacket (which is 0x1400 for high bandwidth isoc).

What about this?


Yeah, seems not right to me too. The UDC would only have 1024 bytes to
transmit.






irq/441-dwc3-769   [001] d..2   101.207682: dwc3_prepare_trb: ep2in-isoc:
trb f2037020 bph  bpl ad9d2000 size 1400 ctrl 0c69


Looks like the "bits 12:11 of wMaxPacketSize" patch from Felipe was not applied.


No, I didn't. I was trying to give a trace for the base line to start
with.

Get it. Waiting for your further testing result.


I am waiting for Felipe's next instruction - going on v4.4.21 tag or his
v4.4.21+dwc3 HEAD.

Is it possible that you try "bits 12:11 of wMaxPacketSize" patches from Felipe
with your current HEAD now?
You may hardcode the req_size (3072) in uvc_video (only for test).

Regards
Yin, Fengwei



Regards,
-Bin.



Regards
Yin, Fengwei



Regards,
-Bin.




irq/441-dwc3-769   [001] d..2   101.208357: dwc3_complete_trb: ep2in-isoc:
trb f2037020 bph  bpl ad9d2000 size 10001400 ctrl 1bfd0c68


MissedIsoc happened.


Regards
Yin, Fengwei


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] usb: add helper to extract bits 12:11 of wMaxPacketSize

2016-09-27 Thread Bin Liu 
On Tue, Sep 27, 2016 at 11:02:54PM +0800, yfw wrote:
> 
> 
> On 2016/9/27 23:00, Bin Liu wrote:
> >On Tue, Sep 27, 2016 at 10:53:54PM +0800, yfw wrote:
> >>Hi,
> >>
> >>On 2016/9/27 22:28, Bin Liu wrote:
> >>>On Tue, Sep 27, 2016 at 09:20:56AM -0500, Bin Liu wrote:
> Felipe,
> 
> On Tue, Sep 27, 2016 at 10:18:26AM +0300, Felipe Balbi wrote:
> 
> [snip]
> 
> Does this mean the issue of isoc high bandwidth transfer was fixed by
> this patchset per your test?
> >>>
> >>>No, I couldn't get g_webcam to work yet.
> >>
> >>In mainline, g_webcam is broken with DWC3. Also these two patches don't
> >>fix the issue on v4.4.21.
> >
> >care to send tracepoint output? Best if you could cherry pick my latest
> >tracepoint changes so we have the best output possible.
> >
> >I have also built a branch with v4.4.21 + all dwc3 patches (except for
> >device properties and PCI stuff) which you could use for testing. If you
> >run with that, then I can get proper trace output and I can try to
> >figure out what's missing.
> >
> >Branch is here:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> > usb/v4.4.21+dwc3
> 
> This branch does not generate the isoch traffic (on ep2in). ftrace
> attached (dwc3-g_webcam-v4.4.21+tp.ftrace).
> 
> I also attached the ftrace log for v4.4.21 tag
> (dwc3-g_webcam-v4.4.21.ftrace) for comparison, which has ep2in isoch
> traffic, but only one transaction per SOF.
> >>>
> >>>Sorry, I didn't realize the ftrace file size is huge. Attached the
> >>>tarball here.
> >>>(dwc3-g_webcam-ftrace.tgz)
> >>>
> >>>Regards,
> >>>-Bin.
> >>>
> >>From the ftrace log:
> >>
> >>>irq/441-dwc3-769   [001] d..2   101.207679: dwc3_gadget: ep2in-isoc: req
> >>>ed971b00 dma ad9d2000 length 5120
> >>5120 looks wrong to me. 5120 == 0x1400. There is an issue in uvc_video which
> >>set the req_size according maxpacket (which is 0x1400 for high bandwidth 
> >>isoc).
> What about this?

Yeah, seems not right to me too. The UDC would only have 1024 bytes to
transmit.

> 
> >>
> >>>irq/441-dwc3-769   [001] d..2   101.207682: dwc3_prepare_trb: ep2in-isoc:
> >>>trb f2037020 bph  bpl ad9d2000 size 1400 ctrl 0c69
> >>
> >>Looks like the "bits 12:11 of wMaxPacketSize" patch from Felipe was not 
> >>applied.
> >
> >No, I didn't. I was trying to give a trace for the base line to start
> >with.
> Get it. Waiting for your further testing result.

I am waiting for Felipe's next instruction - going on v4.4.21 tag or his
v4.4.21+dwc3 HEAD.

Regards,
-Bin.

> 
> Regards
> Yin, Fengwei
> 
> >
> >Regards,
> >-Bin.
> >
> >>
> >>>irq/441-dwc3-769   [001] d..2   101.208357: dwc3_complete_trb: ep2in-isoc:
> >>>trb f2037020 bph  bpl ad9d2000 size 10001400 ctrl 1bfd0c68
> >>
> >>MissedIsoc happened.
> >>
> >>
> >>Regards
> >>Yin, Fengwei
> >>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Strange behavior of CHN bit with dwc3

2016-09-27 Thread yfw 



On 2016/9/27 11:55, mgau...@codeaurora.org wrote:

On 2016-09-22 18:46, yfw wrote:

Hi list,
I tried to enable the high speed, high bandwidth transfer in device
mode for iso type on dwc3 based soc. The platform only supports usb
device 2.0.

I set the MaxPacketSize to 0x1400 so the host could allocate 3072
bytes for uframe. But when I chain three trbs together, the dwc3
behavior is quite weird:



Why are you using three TRBs for one service interval? Is the data
not contiguous?
Since, in your case all 3072 bytes belong to one service interval,
could just one TRB be used with PktCntM1 set to '2' ?


BTW, the configures:
1. 1 trb with one 3072 bytes buffer:
   trb1:  size set to DWC3_TRB_SIZE_PCM1(2) | 0xc00
  DMA = Buffer DMA address
2. 3 trbs with one 3072 bytes buffer:
   trb1: size DWC3_TRB_SIZE_PCM1(2) | 0x400, ctrl with CHN bit set
 DMA = buffer DMA address
   trb2: size: 0x400, ctrl with CHN bit set
 DMA = buffer DMA address + 0x400
   trb3: size: 0x400, ctrl with CHN bit NOT set
 DMA = buffer DMA address + 0x800

should have same behavior. Right?

Regards
Yin, Fengwei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] usb: add helper to extract bits 12:11 of wMaxPacketSize

2016-09-27 Thread yfw 



On 2016/9/27 23:00, Bin Liu wrote:

On Tue, Sep 27, 2016 at 10:53:54PM +0800, yfw wrote:

Hi,

On 2016/9/27 22:28, Bin Liu wrote:

On Tue, Sep 27, 2016 at 09:20:56AM -0500, Bin Liu wrote:

Felipe,

On Tue, Sep 27, 2016 at 10:18:26AM +0300, Felipe Balbi wrote:

[snip]


Does this mean the issue of isoc high bandwidth transfer was fixed by
this patchset per your test?


No, I couldn't get g_webcam to work yet.


In mainline, g_webcam is broken with DWC3. Also these two patches don't
fix the issue on v4.4.21.


care to send tracepoint output? Best if you could cherry pick my latest
tracepoint changes so we have the best output possible.

I have also built a branch with v4.4.21 + all dwc3 patches (except for
device properties and PCI stuff) which you could use for testing. If you
run with that, then I can get proper trace output and I can try to
figure out what's missing.

Branch is here:

 git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git usb/v4.4.21+dwc3


This branch does not generate the isoch traffic (on ep2in). ftrace
attached (dwc3-g_webcam-v4.4.21+tp.ftrace).

I also attached the ftrace log for v4.4.21 tag
(dwc3-g_webcam-v4.4.21.ftrace) for comparison, which has ep2in isoch
traffic, but only one transaction per SOF.


Sorry, I didn't realize the ftrace file size is huge. Attached the
tarball here.
(dwc3-g_webcam-ftrace.tgz)

Regards,
-Bin.


From the ftrace log:


irq/441-dwc3-769   [001] d..2   101.207679: dwc3_gadget: ep2in-isoc: req
ed971b00 dma ad9d2000 length 5120

5120 looks wrong to me. 5120 == 0x1400. There is an issue in uvc_video which
set the req_size according maxpacket (which is 0x1400 for high bandwidth isoc).

What about this?




irq/441-dwc3-769   [001] d..2   101.207682: dwc3_prepare_trb: ep2in-isoc:
trb f2037020 bph  bpl ad9d2000 size 1400 ctrl 0c69


Looks like the "bits 12:11 of wMaxPacketSize" patch from Felipe was not applied.


No, I didn't. I was trying to give a trace for the base line to start
with.

Get it. Waiting for your further testing result.

Regards
Yin, Fengwei



Regards,
-Bin.




irq/441-dwc3-769   [001] d..2   101.208357: dwc3_complete_trb: ep2in-isoc:
trb f2037020 bph  bpl ad9d2000 size 10001400 ctrl 1bfd0c68


MissedIsoc happened.


Regards
Yin, Fengwei


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] usb: add helper to extract bits 12:11 of wMaxPacketSize

2016-09-27 Thread yfw 

Hi,

On 2016/9/27 22:28, Bin Liu wrote:

On Tue, Sep 27, 2016 at 09:20:56AM -0500, Bin Liu wrote:

Felipe,

On Tue, Sep 27, 2016 at 10:18:26AM +0300, Felipe Balbi wrote:

[snip]


Does this mean the issue of isoc high bandwidth transfer was fixed by
this patchset per your test?


No, I couldn't get g_webcam to work yet.


In mainline, g_webcam is broken with DWC3. Also these two patches don't
fix the issue on v4.4.21.


care to send tracepoint output? Best if you could cherry pick my latest
tracepoint changes so we have the best output possible.

I have also built a branch with v4.4.21 + all dwc3 patches (except for
device properties and PCI stuff) which you could use for testing. If you
run with that, then I can get proper trace output and I can try to
figure out what's missing.

Branch is here:

  git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git usb/v4.4.21+dwc3


This branch does not generate the isoch traffic (on ep2in). ftrace
attached (dwc3-g_webcam-v4.4.21+tp.ftrace).

I also attached the ftrace log for v4.4.21 tag
(dwc3-g_webcam-v4.4.21.ftrace) for comparison, which has ep2in isoch
traffic, but only one transaction per SOF.


Sorry, I didn't realize the ftrace file size is huge. Attached the
tarball here.
(dwc3-g_webcam-ftrace.tgz)

Regards,
-Bin.


From the ftrace log:

> irq/441-dwc3-769   [001] d..2   101.207679: dwc3_gadget: ep2in-isoc: req
> ed971b00 dma ad9d2000 length 5120
5120 looks wrong to me. 5120 == 0x1400. There is an issue in uvc_video which
set the req_size according maxpacket (which is 0x1400 for high bandwidth isoc).

> irq/441-dwc3-769   [001] d..2   101.207682: dwc3_prepare_trb: ep2in-isoc:
> trb f2037020 bph  bpl ad9d2000 size 1400 ctrl 0c69

Looks like the "bits 12:11 of wMaxPacketSize" patch from Felipe was not applied.

> irq/441-dwc3-769   [001] d..2   101.208357: dwc3_complete_trb: ep2in-isoc:
> trb f2037020 bph  bpl ad9d2000 size 10001400 ctrl 1bfd0c68

MissedIsoc happened.


Regards
Yin, Fengwei

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] usb: add helper to extract bits 12:11 of wMaxPacketSize

2016-09-27 Thread Bin Liu 
On Tue, Sep 27, 2016 at 10:53:54PM +0800, yfw wrote:
> Hi,
> 
> On 2016/9/27 22:28, Bin Liu wrote:
> >On Tue, Sep 27, 2016 at 09:20:56AM -0500, Bin Liu wrote:
> >>Felipe,
> >>
> >>On Tue, Sep 27, 2016 at 10:18:26AM +0300, Felipe Balbi wrote:
> >>
> >>[snip]
> >>
> >>Does this mean the issue of isoc high bandwidth transfer was fixed by
> >>this patchset per your test?
> >
> >No, I couldn't get g_webcam to work yet.
> 
> In mainline, g_webcam is broken with DWC3. Also these two patches don't
> fix the issue on v4.4.21.
> >>>
> >>>care to send tracepoint output? Best if you could cherry pick my latest
> >>>tracepoint changes so we have the best output possible.
> >>>
> >>>I have also built a branch with v4.4.21 + all dwc3 patches (except for
> >>>device properties and PCI stuff) which you could use for testing. If you
> >>>run with that, then I can get proper trace output and I can try to
> >>>figure out what's missing.
> >>>
> >>>Branch is here:
> >>>
> >>>  git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> >>> usb/v4.4.21+dwc3
> >>
> >>This branch does not generate the isoch traffic (on ep2in). ftrace
> >>attached (dwc3-g_webcam-v4.4.21+tp.ftrace).
> >>
> >>I also attached the ftrace log for v4.4.21 tag
> >>(dwc3-g_webcam-v4.4.21.ftrace) for comparison, which has ep2in isoch
> >>traffic, but only one transaction per SOF.
> >
> >Sorry, I didn't realize the ftrace file size is huge. Attached the
> >tarball here.
> >(dwc3-g_webcam-ftrace.tgz)
> >
> >Regards,
> >-Bin.
> >
> From the ftrace log:
> 
> > irq/441-dwc3-769   [001] d..2   101.207679: dwc3_gadget: ep2in-isoc: req
> > ed971b00 dma ad9d2000 length 5120
> 5120 looks wrong to me. 5120 == 0x1400. There is an issue in uvc_video which
> set the req_size according maxpacket (which is 0x1400 for high bandwidth 
> isoc).
> 
> > irq/441-dwc3-769   [001] d..2   101.207682: dwc3_prepare_trb: ep2in-isoc:
> > trb f2037020 bph  bpl ad9d2000 size 1400 ctrl 0c69
> 
> Looks like the "bits 12:11 of wMaxPacketSize" patch from Felipe was not 
> applied.

No, I didn't. I was trying to give a trace for the base line to start
with.

Regards,
-Bin.

> 
> > irq/441-dwc3-769   [001] d..2   101.208357: dwc3_complete_trb: ep2in-isoc:
> > trb f2037020 bph  bpl ad9d2000 size 10001400 ctrl 1bfd0c68
> 
> MissedIsoc happened.
> 
> 
> Regards
> Yin, Fengwei
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2 3/3] usb: renesas_usbhs: cleanup with list_first_entry_or_null()

2016-09-27 Thread Yoshihiro Shimoda 
Hi Yamada-san,

> From: Masahiro Yamada
> Sent: Monday, September 19, 2016 1:03 AM
> 
> The combo of list_empty() check and return list_first_entry()
> can be replaced with list_first_entry_or_null().
> 
> Signed-off-by: Masahiro Yamada 

Thank you for the patch!

Acked-by: Yoshihiro Shimoda 

Best regards,
Yoshihiro Shimoda

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

2016-09-27 Thread Mathias Nyman 

On 27.09.2016 03:03, Pierre de Villemereuil wrote:

Hi guys,

Any news on this front? Anything I can do to help find the issue?



A couple more logs just to clarify a few things.

run:
sudo lspci -d :8c31 -vv

both when AC is connected (the state where it detects usb devices)
and when not connected (state when usb devive detection fails)

It should show the pci state of the controller (D0 is up and running, D3 is 
suspended)
if in D3 it should show that PME is enabled.
A usb connect event should generate a PME that then wakes up the xHC host from 
D3.

Did I understand correctly that there was nothing in dmesg if AC is unplugged
when connecting a usb device? Not even with enhanced xhci debugging enabled?

Is there anything that looks suspicious in BIOS?
An option that disables wake up events for usb ports? or disables
usb ports, Energy saver support EuP/ErP?

-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: ARM juno R2 board USB Issue (EHCI probe failed)

2016-09-27 Thread Sajjan, Vikas C 
Hi Sudeep,

-Original Message-
From: Sudeep Holla [mailto:sudeep.ho...@arm.com] 
Sent: Tuesday, September 27, 2016 2:21 PM
To: Vikas Sajjan ; linux-usb@vger.kernel.org; 
linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org
Cc: Sudeep Holla ; mark.rutl...@arm.com; 
lorenzo.pieral...@arm.com; Sajjan, Vikas C 
Subject: Re: ARM juno R2 board USB Issue (EHCI probe failed)

Hi Vikas,

On 27/09/16 09:14, Vikas Sajjan wrote:
> Adding USB mailing list.
>
>
> On Tue, Sep 27, 2016 at 12:33 PM, Sajjan, Vikas C 
>  wrote:
>> Hi All,
>>
>> I working on ARM juno R2 board, with latest kernel 4.8.rc7 and I get 
>> below USB EHCI probe error while booting with acpi=force.
>>

Are you using the latest UEFI EDK2 ?
No, I am still using the UEFI binary which came as part of the Juno board.


>> [1.223662] VFIO - User Level meta-driver version: 0.3
>> [1.229335] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
>> [1.235882] ehci-pci: EHCI PCI platform driver
>> [1.240359] ehci-platform: EHCI generic platform driver
>> [1.245619] ehci-platform ARMH0D20:00: Error: DMA mask configuration 
>> failed
>> [1.272491] ehci-platform: probe of ARMH0D20:00 failed with error -5
>> [1.278876] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
>> [1.285071] ohci-pci: OHCI PCI platform driver
>> [1.289548] ohci-platform: OHCI generic platform driver
>> [1.294884] usbcore: registered new interface driver usb-storage
>> [1.301231] mousedev: PS/2 mouse device common for all mice
>> [1.307197] rtc-efi rtc-efi: rtc core: registered rtc-efi as rtc0
>>
>> But this error goes off, if I don't force ACPI booting, i.e., if I 
>> remove acpi=force from kernel command line , USB is detected  and my 
>> RFS which is in the usb drive, gets mounted successfully.
>>

As I mentioned in private, I do get the same error if I drop _CCA in USB object 
of ACPI DSDT. Can you give it a spin with latest UEFI ?

Sure, will try with latest UEFI.

Thanks and Regards
Vikas Sajjan
--
Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: BUG: scheduling while atomic in f_fs when gadget remove driver

2016-09-27 Thread Felipe Balbi 

Hi,

Chen Yu  writes:
> Hi All,
>
> I'm working on Hikey board based around the HiSilicon Kirin 620, with
> linaro kernel version 4.8.rc1 and I get below BUG error while
> extracting USB cable from PC.

which peripheral controller does this one have? Is it dwc3?

I'm very interested in knowing about throughtput of adb push with dwc3 + f_fs.

Also, do you know if adb can run outside of android environment? I've
been looking for a proper functionfs user for quite some time now :-(

> The funtion using f_fs is adb and usb_gadget_unregister_driver will be
> called after extracting USB cable from PC.
>
> [   89.456512s][pid:1,cpu1,init]BUG: scheduling while atomic: 
> init/1/0x0002
> [   89.456573s]Modules linked in:
> [   89.456604s]Preemption disabled at:[] 
> composite_disconnect+0x30/0xac
> [   89.456665s][pid:1,cpu1,init]TGID: 1 Comm: init
> [   89.456695s][pid:1,cpu1,init]Call trace:
> [   89.456726s][pid:1,cpu1,init][] dump_backtrace+0x0/0x15c
> [   89.456756s][pid:1,cpu1,init][] show_stack+0x20/0x28
> [   89.456756s][pid:1,cpu1,init][] dump_stack+0x84/0xa8
> [   89.456787s][pid:1,cpu1,init][] __schedule_bug+0x88/0xdc
> [   89.456817s][pid:1,cpu1,init][] __schedule+0x714/0x854
> [   89.456817s][pid:1,cpu1,init][] schedule+0x48/0xa4
> [   89.456817s][pid:1,cpu1,init][] 
> schedule_preempt_disabled+0x4c/0xf4
> [   89.456848s][pid:1,cpu1,init][] 
> __mutex_lock_slowpath+0xbc/0x1a4
> [   89.456878s][pid:1,cpu1,init][] mutex_lock+0x60/0x64
> [   89.456878s][pid:1,cpu1,init][] 
> ffs_func_eps_disable.isra.17+0x54/0x114
> [   89.456909s][pid:1,cpu1,init][] 
> ffs_func_disable+0x30/0xa0
> [   89.456909s][pid:1,cpu1,init][] 
> reset_config.isra.8+0x44/0x78
> [   89.456939s][pid:1,cpu1,init][] 
> composite_disconnect+0x48/0xac
> [   89.456939s][pid:1,cpu1,init][] 
> android_disconnect+0x48/0x54
> [   89.456970s][pid:1,cpu1,init][] 
> usb_gadget_remove_driver+0x58/0xa0
> [   89.456970s][pid:1,cpu1,init][] 
> usb_gadget_unregister_driver+0x78/0xc4
>
> I checked the codes of composite_disconnect and found
> spin_lock_irqsave called before reset_config in which
> ffs_func_eps_disable is called.
>
> void composite_disconnect(struct usb_gadget *gadget)
> {
> struct usb_composite_dev*cdev = get_gadget_data(gadget);
> unsigned long   flags;
>
> /* REVISIT:  should we have config and device level
>  * disconnect callbacks?
>  */
> spin_lock_irqsave(>lock, flags);
> if (cdev->config)
> reset_config(cdev);
> if (cdev->driver->disconnect)
> cdev->driver->disconnect(cdev);
> spin_unlock_irqrestore(>lock, flags);
> }
>
> static void ffs_func_eps_disable(struct ffs_function *func)
> {
> struct ffs_ep *ep = func->eps;
> struct ffs_epfile *epfile = func->ffs->epfiles;
> unsigned count= func->ffs->eps_count;
> unsigned long flags;
>
> do {
> if (epfile)
> mutex_lock(>mutex);
> spin_lock_irqsave(>ffs->eps_lock, flags);
> /* pending requests get nuked */
> if (likely(ep->ep))
> usb_ep_disable(ep->ep);
> ++ep;
> spin_unlock_irqrestore(>ffs->eps_lock, flags);
>
> if (epfile) {
> epfile->ep = NULL;
> kfree(epfile->read_buffer);
> epfile->read_buffer = NULL;
> mutex_unlock(>mutex);
> ++epfile;
> }
> } while (--count);
> }
>
> Should the epfile->read_buffer be cleared another place and the
> mutex_lock can be removed in ffs_func_eps_disable?

You are correct. There's a bug there. Can you try to propose a fix for
it?

thanks

-- 
balbi


signature.asc
Description: PGP signature

BUG: scheduling while atomic in f_fs when gadget remove driver

2016-09-27 Thread Chen Yu 
Hi All,

I'm working on Hikey board based around the HiSilicon Kirin 620, with linaro 
kernel version 4.8.rc1 and I
get below BUG error while extracting USB cable from PC.

The funtion using f_fs is adb and usb_gadget_unregister_driver will be called 
after extracting USB cable from PC.

[   89.456512s][pid:1,cpu1,init]BUG: scheduling while atomic: init/1/0x0002
[   89.456573s]Modules linked in:
[   89.456604s]Preemption disabled at:[] 
composite_disconnect+0x30/0xac
[   89.456665s][pid:1,cpu1,init]TGID: 1 Comm: init
[   89.456695s][pid:1,cpu1,init]Call trace:
[   89.456726s][pid:1,cpu1,init][] dump_backtrace+0x0/0x15c
[   89.456756s][pid:1,cpu1,init][] show_stack+0x20/0x28
[   89.456756s][pid:1,cpu1,init][] dump_stack+0x84/0xa8
[   89.456787s][pid:1,cpu1,init][] __schedule_bug+0x88/0xdc
[   89.456817s][pid:1,cpu1,init][] __schedule+0x714/0x854
[   89.456817s][pid:1,cpu1,init][] schedule+0x48/0xa4
[   89.456817s][pid:1,cpu1,init][] 
schedule_preempt_disabled+0x4c/0xf4
[   89.456848s][pid:1,cpu1,init][] 
__mutex_lock_slowpath+0xbc/0x1a4
[   89.456878s][pid:1,cpu1,init][] mutex_lock+0x60/0x64
[   89.456878s][pid:1,cpu1,init][] 
ffs_func_eps_disable.isra.17+0x54/0x114
[   89.456909s][pid:1,cpu1,init][] ffs_func_disable+0x30/0xa0
[   89.456909s][pid:1,cpu1,init][] 
reset_config.isra.8+0x44/0x78
[   89.456939s][pid:1,cpu1,init][] 
composite_disconnect+0x48/0xac
[   89.456939s][pid:1,cpu1,init][] 
android_disconnect+0x48/0x54
[   89.456970s][pid:1,cpu1,init][] 
usb_gadget_remove_driver+0x58/0xa0
[   89.456970s][pid:1,cpu1,init][] 
usb_gadget_unregister_driver+0x78/0xc4

I checked the codes of composite_disconnect and found spin_lock_irqsave called 
before reset_config in which
ffs_func_eps_disable is called.

void composite_disconnect(struct usb_gadget *gadget)
{
struct usb_composite_dev*cdev = get_gadget_data(gadget);
unsigned long   flags;

/* REVISIT:  should we have config and device level
 * disconnect callbacks?
 */
spin_lock_irqsave(>lock, flags);
if (cdev->config)
reset_config(cdev);
if (cdev->driver->disconnect)
cdev->driver->disconnect(cdev);
spin_unlock_irqrestore(>lock, flags);
}

static void ffs_func_eps_disable(struct ffs_function *func)
{
struct ffs_ep *ep = func->eps;
struct ffs_epfile *epfile = func->ffs->epfiles;
unsigned count= func->ffs->eps_count;
unsigned long flags;

do {
if (epfile)
mutex_lock(>mutex);
spin_lock_irqsave(>ffs->eps_lock, flags);
/* pending requests get nuked */
if (likely(ep->ep))
usb_ep_disable(ep->ep);
++ep;
spin_unlock_irqrestore(>ffs->eps_lock, flags);

if (epfile) {
epfile->ep = NULL;
kfree(epfile->read_buffer);
epfile->read_buffer = NULL;
mutex_unlock(>mutex);
++epfile;
}
} while (--count);
}

Should the epfile->read_buffer be cleared another place and the mutex_lock can 
be removed in ffs_func_eps_disable?

Thanks and Regards
Chen Yu

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ARM juno R2 board USB Issue (EHCI probe failed)

2016-09-27 Thread Sudeep Holla 



On 27/09/16 09:55, Sajjan, Vikas C wrote:

Hi Sudeep,

-Original Message-
From: Sudeep Holla [mailto:sudeep.ho...@arm.com]
Sent: Tuesday, September 27, 2016 2:21 PM
To: Vikas Sajjan ; linux-usb@vger.kernel.org; 
linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org
Cc: Sudeep Holla ; mark.rutl...@arm.com; 
lorenzo.pieral...@arm.com; Sajjan, Vikas C 
Subject: Re: ARM juno R2 board USB Issue (EHCI probe failed)

Hi Vikas,

On 27/09/16 09:14, Vikas Sajjan wrote:

Adding USB mailing list.


On Tue, Sep 27, 2016 at 12:33 PM, Sajjan, Vikas C
 wrote:

Hi All,

I working on ARM juno R2 board, with latest kernel 4.8.rc7 and I get
below USB EHCI probe error while booting with acpi=force.



Are you using the latest UEFI EDK2 ?
No, I am still using the UEFI binary which came as part of the Juno board.



[1.223662] VFIO - User Level meta-driver version: 0.3
[1.229335] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[1.235882] ehci-pci: EHCI PCI platform driver
[1.240359] ehci-platform: EHCI generic platform driver
[1.245619] ehci-platform ARMH0D20:00: Error: DMA mask configuration failed
[1.272491] ehci-platform: probe of ARMH0D20:00 failed with error -5
[1.278876] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[1.285071] ohci-pci: OHCI PCI platform driver
[1.289548] ohci-platform: OHCI generic platform driver
[1.294884] usbcore: registered new interface driver usb-storage
[1.301231] mousedev: PS/2 mouse device common for all mice
[1.307197] rtc-efi rtc-efi: rtc core: registered rtc-efi as rtc0

But this error goes off, if I don't force ACPI booting, i.e., if I
remove acpi=force from kernel command line , USB is detected  and my
RFS which is in the usb drive, gets mounted successfully.



As I mentioned in private, I do get the same error if I drop _CCA in
USB object of ACPI DSDT. Can you give it a spin with latest UEFI ?

Sure, will try with latest UEFI.



I bet that's 8-12 months old. It puts the banner during boot with the
build date. You can try to follow [1] or access it from [2]

--
Regards,
Sudeep

[1] https://community.arm.com/docs/DOC-11395
[2] 
http://snapshots.linaro.org/member-builds/armlt-platforms-release/32/juno-uefi.zip

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ARM juno R2 board USB Issue (EHCI probe failed)

2016-09-27 Thread Vikas Sajjan 
Adding USB mailing list.


On Tue, Sep 27, 2016 at 12:33 PM, Sajjan, Vikas C
 wrote:
> Hi All,
>
> I working on ARM juno R2 board, with latest kernel 4.8.rc7 and I get below 
> USB EHCI probe error while booting with acpi=force.
>
> EFI stub: Booting Linux Kernel...
> ConvertPages: Incompatible memory types
> EFI stub: Using DTB from command line
> EFI stub: Exiting boot services and installing virtual address map...
> [0.00] Booting Linux on physical CPU 0x100
> [0.00] Linux version 4.8.0-rc7-00142-gb1f2beb (vikas@dctxvm241) (gcc 
> version 4.8.3 20140401 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2014.04 - 
> Linaro GCC 4.8-2014.04) ) #48 SMP PREEMPT Mon Sep 26 15:31:48 IST 2016
> [0.00] Boot CPU: AArch64 Processor [410fd033]
> [0.00] efi: Getting EFI parameters from FDT:
> [0.00] efi: EFI v2.50 by ARM Juno EFI Oct 15 2015 14:16:39
> [0.00] efi:  ACPI=0xfe75  ACPI 2.0=0xfe750014  PROP=0xfe794370
> [0.00] cma: Reserved 16 MiB at 0xfd40
> [0.00] ACPI: Early table checksum verification disabled
> [0.00] ACPI: RSDP 0xFE750014 24 (v02 ARMLTD)
> [0.00] ACPI: XSDT 0xFE7400E8 3C (v01 ARMLTD ARM-JUNO 
> 20140727  0113)
> [0.00] ACPI: FACP 0xFE72 00010C (v05 ARMLTD ARM-JUNO 
> 20140727 ARM  0099)
> [0.00] ACPI: DSDT 0xFE6F 000317 (v01 ARMLTD ARM-JUNO 
> 20140727 INTL 20140214)
> [0.00] ACPI: GTDT 0xFE71 60 (v02 ARMLTD ARM-JUNO 
> 20140727 ARM  0099)
> [0.00] ACPI: APIC 0xFE70 000224 (v01 ARMLTD ARM-JUNO 
> 20140727 ARM  0099)
> [0.00] psci: probing for conduit method from ACPI.
> [0.00] psci: PSCIv1.0 detected in firmware.
> [0.00] psci: Using standard PSCI v0.2 function IDs
> [0.00] psci: MIGRATE_INFO_TYPE not supported.
> [0.00] percpu: Embedded 21 pages/cpu @80097feb8000 s47488 r8192 
> d30336 u86016
> [0.00] Detected VIPT I-cache on CPU0
> [0.00] CPU features: enabling workaround for ARM erratum 845719
> [0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
> pages: 2060048
> [0.00] Kernel command line: dtb=board.dtb initrd=ramdisk.img 
> console=ttyAMA0,115200 acpi=force root=/dev/sda1
> [0.00] log_buf_len individual max cpu contribution: 4096 bytes
> [0.00] log_buf_len total cpu_extra contributions: 20480 bytes
> . .  . . . .  . .
> . .  . . . .  . .
> . .  . . . .  . .
> . .  . . . .  . .
> [1.223662] VFIO - User Level meta-driver version: 0.3
> [1.229335] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [1.235882] ehci-pci: EHCI PCI platform driver
> [1.240359] ehci-platform: EHCI generic platform driver
> [1.245619] ehci-platform ARMH0D20:00: Error: DMA mask configuration failed
> [1.272491] ehci-platform: probe of ARMH0D20:00 failed with error -5
> [1.278876] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> [1.285071] ohci-pci: OHCI PCI platform driver
> [1.289548] ohci-platform: OHCI generic platform driver
> [1.294884] usbcore: registered new interface driver usb-storage
> [1.301231] mousedev: PS/2 mouse device common for all mice
> [1.307197] rtc-efi rtc-efi: rtc core: registered rtc-efi as rtc0
>
> But this error goes off, if I don't force ACPI booting, i.e., if I remove 
> acpi=force from kernel command line , USB is detected  and my RFS which is in 
> the usb drive, gets mounted successfully.
>
> Thanks and Regards
> Vikas Sajjan
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Strange behavior of CHN bit with dwc3

2016-09-27 Thread Felipe Balbi 

Hi,

mgau...@codeaurora.org writes:
> On 2016-09-22 18:46, yfw wrote:
>> Hi list,
>> I tried to enable the high speed, high bandwidth transfer in device
>> mode for iso type on dwc3 based soc. The platform only supports usb
>> device 2.0.
>> 
>> I set the MaxPacketSize to 0x1400 so the host could allocate 3072
>> bytes for uframe. But when I chain three trbs together, the dwc3
>> behavior is quite weird:
>> 
>
> Why are you using three TRBs for one service interval? Is the data
> not contiguous?

right, if the data isn't contiguous then you MUST use a scatterlist so
driver knows to use CHN bit. If it is contiguous, you can send a single
struct usb_request with size 3072.

> Since, in your case all 3072 bytes belong to one service interval,
> could just one TRB be used with PktCntM1 set to '2' ?

currently, dwc3 doesn't set PktCntM1. I have provided patches setting
that, however.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 1/2] usb: add helper to extract bits 12:11 of wMaxPacketSize

2016-09-27 Thread Felipe Balbi 

Hi,

Bin Liu  writes:
>> >> @@ -630,6 +635,20 @@ static inline int usb_endpoint_maxp(const struct 
>> >> usb_endpoint_descriptor *epd)
>> >>   return __le16_to_cpu(epd->wMaxPacketSize);
>> >>  }
>> >>
>> >> +/**
>> >> + * usb_endpoint_isoc_maxp_mult - get endpoint's transactional 
>> >> opportunities
>> >> + * @epd: endpoint to be checked
>> >> + *
>> >> + * Return @epd's wMaxPacketSize[12:11] + 1
>> >> + */
>> >> +static inline int
>> >> +usb_endpoint_isoc_maxp_mult(const struct usb_endpoint_descriptor *epd)
>> >> +{
>> >> + int maxp = __le16_to_cpu(epd->wMaxPacketSize);
>> >> +
>> >> + return USB_EP_ISOC_MAXP_MULT(maxp) + 1;
>> >> +}
>> >> +
>> >>  static inline int usb_endpoint_interrupt_type(
>> >>   const struct usb_endpoint_descriptor *epd)
>> >>  {
>> >>
>> > Does this mean the issue of isoc high bandwidth transfer was fixed by
>> > this patchset per your test?
>> 
>> No, I couldn't get g_webcam to work yet.
>
> In mainline, g_webcam is broken with DWC3. Also these two patches don't
> fix the issue on v4.4.21.

care to send tracepoint output? Best if you could cherry pick my latest
tracepoint changes so we have the best output possible.

I have also built a branch with v4.4.21 + all dwc3 patches (except for
device properties and PCI stuff) which you could use for testing. If you
run with that, then I can get proper trace output and I can try to
figure out what's missing.

Branch is here:

  git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git usb/v4.4.21+dwc3

thanks

-- 
balbi


signature.asc
Description: PGP signature

Re: g_webcam Isoch high bandwidth transfer

2016-09-27 Thread Felipe Balbi 

Hi,

Bin Liu  writes:
> On Fri, Sep 23, 2016 at 10:49:57AM +0300, Felipe Balbi wrote:
>> 
>> Hi,
>> 
>> Bin Liu  writes:
>> > +Fengwei Yin per his request.
>> >
>> > On Thu, Sep 22, 2016 at 10:48:40PM +0300, Felipe Balbi wrote:
>> >> 
>> >> Hi,
>> >> 
>> >> Bin Liu  writes:
>> >> 
>> >> [...]
>> >> 
>> >> >> Here's one that actually compiles, sorry about that.
>> >> >
>> >> > No worries, I was sleeping ;-)
>> >> >
>> >> > I will test it out early next week. Thanks.
>> >> 
>> >> meanwhile, how about some instructions on how to test this out myself?
>> >> How are you using g_webcam and what are you running on host side? Got a
>> >> nice list of commands there I can use? I think I can get to bottom of
>> >> this much quicker if I can reproduce it locally ;-)
>> >
>> > On device side:
>> > - first patch g_webcam as in my first email in this thread to enable
>> >   640x480@30fps;
>> > - # modprobe g_webcam streaming_maxpacket=3072
>> > - then run uvc-gadget to feed the YUV frames;
>> >http://git.ideasonboard.org/uvc-gadget.git
>> 
>> as is, g_webcam never enumerates to the host. It's calls to
>
> Right, on mainline kernel (I tested 4.8.0-rc7) g_webcam is broken with
> DWC3, g_webcam does not enumerate on the host. But it works on v4.4.21.

There aren't that many changes related to g_webcam though.

$ git log --oneline --no-merges v4.4..HEAD -- 
drivers/usb/gadget/function/f_uvc.c drivers/usb/gadget/legacy/webcam.c 
drivers/usb/gadget/function/uvc*
4fbac5206afd usb: gadget: uvc: Add missing call for additional setup data
bd610c5aa9fc usb: gadget: uvc: Fix return value in case of error
36c0f8b32c4b [media] vb2: replace void *alloc_ctxs by struct device *alloc_devs
1ae1602de028 configfs: switch ->default groups to a linked list
d6dd645eae76 [media] media: videobuf2: Move timestamp to vb2_buffer
df9ecb0cad14 [media] vb2: drop v4l2_format argument from queue_setup
0aecfc1b359d usb: gadget: composite: remove redundant bcdUSB setting in legacy

>> uvc-gadget keeps printing this error message:
>> 
>>  159 if ((ret = ioctl(dev->fd, VIDIOC_DQBUF, )) < 0) {
>>  160 printf("Unable to dequeue buffer: %s (%d).\n", 
>> strerror(errno),
>>  161 errno);
>>  162 return ret;
>>  163 }
>
> I removed this printf, since it floods the console if start uvc-gadget
> before connect to the host.

fair enough

> BTY, you don't have to start uvc-gadget first then connect usb cable. I
> keep the cable always connected.

good to know. Thanks

-- 
balbi


signature.asc
Description: PGP signature

Re: g_webcam Isoch high bandwidth transfer

2016-09-27 Thread Felipe Balbi 

Hi,

Laurent Pinchart  writes:
> Hi Felipe,
>
> On Friday 23 Sep 2016 11:27:26 Felipe Balbi wrote:
>> yfw  writes:
>> >> Here's one that actually compiles, sorry about that.
>> > 
>> > No worries, I was sleeping ;-)
>> > 
>> > I will test it out early next week. Thanks.
>>  
>>  meanwhile, how about some instructions on how to test this out myself?
>>  How are you using g_webcam and what are you running on host side? Got a
>>  nice list of commands there I can use? I think I can get to bottom of
>>  this much quicker if I can reproduce it locally ;-)
>> >>> 
>> >>> On device side:
>> >>> - first patch g_webcam as in my first email in this thread to enable
>> >>>   640x480@30fps;
>> >>> - # modprobe g_webcam streaming_maxpacket=3072
>> >>> - then run uvc-gadget to feed the YUV frames;
>> >>>  http://git.ideasonboard.org/uvc-gadget.git
>> >> 
>> >> as is, g_webcam never enumerates to the host. It's calls to
>> >> usb_function_active() and usb_function_deactivate() are unbalanced. Do
>> >> you have any other changes to g_webcam?
>> > 
>> > With uvc function gadget driver, user daemon uvc-gadget must be started
>> > before connect to host. Not sure whether g_webcam has same requirement.
>> 
>> f_uvc.c should be handling that by means for usb_function_deactivate().
>> 
>> I'll try keeping cable disconnected until uvc-gadget is running.
>
> Things might have changed since we've discussed the issue several years ago, 
> but back then at least the musb UDC started unconditionally connected.

That's kinda of not the case anymore. We deactivate during function
registration if a certain flag is set.

-- 
balbi


signature.asc
Description: PGP signature