Re: [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP booting

2016-05-02 Thread Krzysztof Kozlowski
On 05/02/2016 03:40 PM, Hans Verkuil wrote:
>>> Anyway, after disabling that config option I was finally able to test your 
>>> patch
>>> series:
>>>
>>> Tested-by: Hans Verkuil 
> 
> BTW, one thing I noticed is that to have u-boot detect the network device I
> need to call 'usb reset' twice. This is with u-boot 2016.1 release.
> 
> Not a big deal, but I wondered if you see the same.

Yes, I also have to do it twice.

Best regards,
Krzysztof



Re: [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP booting

2016-05-02 Thread Krzysztof Kozlowski
On 05/02/2016 03:40 PM, Hans Verkuil wrote:
>>> Anyway, after disabling that config option I was finally able to test your 
>>> patch
>>> series:
>>>
>>> Tested-by: Hans Verkuil 
> 
> BTW, one thing I noticed is that to have u-boot detect the network device I
> need to call 'usb reset' twice. This is with u-boot 2016.1 release.
> 
> Not a big deal, but I wondered if you see the same.

Yes, I also have to do it twice.

Best regards,
Krzysztof



Re: [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP booting

2016-05-02 Thread Hans Verkuil
On 05/01/16 18:42, Krzysztof Kozlowski wrote:
> On Sun, May 01, 2016 at 06:01:08PM +0200, Hans Verkuil wrote:
>>> Sorry, I meant the hanging issue I got in 4.6, not the ethernet issue.
>>> I get the same problem with linux-next. Can you mail me the .config you are 
>>> using?
>>
>> Never mind.
>>
>>> After some more testing I don't think it is hanging, instead it seems that 
>>> the mmc
>>> isn't enabled/found and so it just sits waiting for the root partition to 
>>> appear.
>>
>> That was fun. There are two problems that both caused the boot to end at the 
>> same
>> place: first of all the root partition is now called mmcblk1p1 instead of 
>> mmcblk0p1
>> in 4.6, so it was just waiting for the root partition to appear. Nothing to 
>> do with
>> your patch series, just unexpected.
> 
> Yes, annoying issue and unfortunately this is known... recommended
> solution is to use root=PARTUUID= (you can get the PARTUUID with
> blkid)... or replace the mmc device.
> 
>> The second is that enabling CONFIG_VIDEO_S5P_FIMC causes the boot to hang at 
>> that
>> same place. I suspect there is a deadlock somewhere. I'm digging deeper into 
>> that
>> but again, unrelated to your patch series.
>>
>> Anyway, after disabling that config option I was finally able to test your 
>> patch
>> series:
>>
>> Tested-by: Hans Verkuil 

BTW, one thing I noticed is that to have u-boot detect the network device I
need to call 'usb reset' twice. This is with u-boot 2016.1 release.

Not a big deal, but I wondered if you see the same.

Regards,

Hans


Re: [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP booting

2016-05-02 Thread Hans Verkuil
On 05/01/16 18:42, Krzysztof Kozlowski wrote:
> On Sun, May 01, 2016 at 06:01:08PM +0200, Hans Verkuil wrote:
>>> Sorry, I meant the hanging issue I got in 4.6, not the ethernet issue.
>>> I get the same problem with linux-next. Can you mail me the .config you are 
>>> using?
>>
>> Never mind.
>>
>>> After some more testing I don't think it is hanging, instead it seems that 
>>> the mmc
>>> isn't enabled/found and so it just sits waiting for the root partition to 
>>> appear.
>>
>> That was fun. There are two problems that both caused the boot to end at the 
>> same
>> place: first of all the root partition is now called mmcblk1p1 instead of 
>> mmcblk0p1
>> in 4.6, so it was just waiting for the root partition to appear. Nothing to 
>> do with
>> your patch series, just unexpected.
> 
> Yes, annoying issue and unfortunately this is known... recommended
> solution is to use root=PARTUUID= (you can get the PARTUUID with
> blkid)... or replace the mmc device.
> 
>> The second is that enabling CONFIG_VIDEO_S5P_FIMC causes the boot to hang at 
>> that
>> same place. I suspect there is a deadlock somewhere. I'm digging deeper into 
>> that
>> but again, unrelated to your patch series.
>>
>> Anyway, after disabling that config option I was finally able to test your 
>> patch
>> series:
>>
>> Tested-by: Hans Verkuil 

BTW, one thing I noticed is that to have u-boot detect the network device I
need to call 'usb reset' twice. This is with u-boot 2016.1 release.

Not a big deal, but I wondered if you see the same.

Regards,

Hans


Re: [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP booting

2016-05-01 Thread Marek Szyprowski

Hi Hans,


On 2016-05-01 18:01, Hans Verkuil wrote:

On 05/01/2016 04:09 PM, Hans Verkuil wrote:

On 05/01/2016 03:17 PM, Krzysztof Kozlowski wrote:

On Sat, Apr 30, 2016 at 11:43:44AM +0200, Hans Verkuil wrote:

Hi Krzysztof,

On 04/29/2016 12:59 PM, Krzysztof Kozlowski wrote:

Hi,

Patches are independent, please pick up as you wish.

However all of them are needed to solve the issue, so I am sending
everything together for easier testng.


Problem
===
When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
the usb3503 does not show up in "lsusb". Hard-reset is required, e.g.
by suspend to RAM. The actual TFTP boot does not have to happen. Just
"usb start" from U-Boot is sufficient.


Solution

Perform real hardware reset (including regulator off/on) when probing.


Tested on Odroid U3 so far. Please kindly test on X2 and other
configurations and bootloaders.

Against which kernel git repo is this patch?

I did apply this patch series first:

http://www.spinics.net/lists/arm-kernel/msg500764.html

Indeed it is based on above patchset... and on linux-next. It touches
multiple trees so next seems the easiest base.


followed by this patch series.

I've tested with both 4.6.0-rc2 and -rc5, but in all cases (even without
applying these patches!) the boot sequence hangs here:

...
[drm] Exynos DRM: using 12c1.mixer device for DMA mapping operations
exynos-drm exynos-drm: bound 12c1.mixer (ops mixer_component_ops)
exynos-drm exynos-drm: bound 12d0.hdmi (ops hdmi_component_ops)
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.
Console: switching to colour frame buffer device 240x67
exynos-drm exynos-drm: fb0:  frame buffer device
[drm] Initialized exynos 1.0.0 20110530 on minor 0
brd: module loaded
loop: module loaded
s3c64xx-spi 1393.spi: spi bus clock parent not specified, using clock
at index 0 as parent
s3c64xx-spi 1393.spi: number of chip select lines not specified,
assuming 1 chip select line
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky 
usbcore: registered new interface driver asix
usbcore: registered new interface driver ax88179_178a
usbcore: registered new interface driver cdc_ether
usbcore: registered new interface driver smsc95xx
usbcore: registered new interface driver cdc_ncm
dwc2 1248.hsotg: Specified GNPTXFDEP=1024 > 768
dwc2 1248.hsotg: EPs: 16, dedicated fifos, 7808 entries in SPRAM
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-exynos: EHCI EXYNOS driver
exynos-ehci 1258.ehci: EHCI Host Controller
exynos-ehci 1258.ehci: new USB bus registered, assigned bus number 1
exynos-ehci 1258.ehci: irq 51, io mem 0x1258
exynos-ehci 1258.ehci: USB 2.0 started, EHCI 1.00
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 4.6.0-rc5-odroid ehci_hcd
usb usb1: SerialNumber: 1258.ehci
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci-exynos: OHCI EXYNOS driver
usbcore: registered new interface driver usb-storage
usb3503 0-0008: switched to HUB mode
usb3503 0-0008: usb3503_probe: probed in hub mode
using random self ethernet address
using random host ethernet address
usb0: HOST MAC 66:79:ef:11:72:85
usb0: MAC 1e:66:f2:66:8e:2a
using random self ethernet address
using random host ethernet address
g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
g_ether gadget: g_ether ready
dwc2 1248.hsotg: bound driver g_ether
mousedev: PS/2 mouse device common for all mice
max77686-rtc max77686-rtc: rtc core: registered max77686-rtc as rtc0
i2c /dev entries driver
s5p-fimc-md camera: Entity type for entity FIMC.0 was not initialized!
usb 1-2: new high-speed USB device number 2 using exynos-ehci
usb 1-2: New USB device found, idVendor=0424, idProduct=9730
usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
smsc95xx v1.0.4
smsc95xx 1-2:1.0 eth0: register 'smsc95xx' at usb-1258.ehci-2, smsc95xx
USB 2.0 Ethernet, c2:22:09:f2:5f:e8
usb 1-3: new high-speed USB device number 3 using exynos-ehci
usb 1-3: New USB device found, idVendor=0424, idProduct=3503
usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
hub 1-3:1.0: USB hub found
hub 1-3:1.0: 3 ports detected

No oops, no nothing. It's just sitting there.

Apparently you have encountered different issue. sysrq with 'l' might be
useful.


Is this a regression that was introduced in 4.6? Or is there some special
new config that needs to be turned on first in 4.6?

I think it was like that for looong time... although I did not use
netboot before on that target.

Sorry, I meant the hanging issue I got in 4.6, not the ethernet issue.
I get the same problem with linux-next. Can you mail me the .config you are 
using?


Re: [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP booting

2016-05-01 Thread Marek Szyprowski

Hi Hans,


On 2016-05-01 18:01, Hans Verkuil wrote:

On 05/01/2016 04:09 PM, Hans Verkuil wrote:

On 05/01/2016 03:17 PM, Krzysztof Kozlowski wrote:

On Sat, Apr 30, 2016 at 11:43:44AM +0200, Hans Verkuil wrote:

Hi Krzysztof,

On 04/29/2016 12:59 PM, Krzysztof Kozlowski wrote:

Hi,

Patches are independent, please pick up as you wish.

However all of them are needed to solve the issue, so I am sending
everything together for easier testng.


Problem
===
When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
the usb3503 does not show up in "lsusb". Hard-reset is required, e.g.
by suspend to RAM. The actual TFTP boot does not have to happen. Just
"usb start" from U-Boot is sufficient.


Solution

Perform real hardware reset (including regulator off/on) when probing.


Tested on Odroid U3 so far. Please kindly test on X2 and other
configurations and bootloaders.

Against which kernel git repo is this patch?

I did apply this patch series first:

http://www.spinics.net/lists/arm-kernel/msg500764.html

Indeed it is based on above patchset... and on linux-next. It touches
multiple trees so next seems the easiest base.


followed by this patch series.

I've tested with both 4.6.0-rc2 and -rc5, but in all cases (even without
applying these patches!) the boot sequence hangs here:

...
[drm] Exynos DRM: using 12c1.mixer device for DMA mapping operations
exynos-drm exynos-drm: bound 12c1.mixer (ops mixer_component_ops)
exynos-drm exynos-drm: bound 12d0.hdmi (ops hdmi_component_ops)
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.
Console: switching to colour frame buffer device 240x67
exynos-drm exynos-drm: fb0:  frame buffer device
[drm] Initialized exynos 1.0.0 20110530 on minor 0
brd: module loaded
loop: module loaded
s3c64xx-spi 1393.spi: spi bus clock parent not specified, using clock
at index 0 as parent
s3c64xx-spi 1393.spi: number of chip select lines not specified,
assuming 1 chip select line
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky 
usbcore: registered new interface driver asix
usbcore: registered new interface driver ax88179_178a
usbcore: registered new interface driver cdc_ether
usbcore: registered new interface driver smsc95xx
usbcore: registered new interface driver cdc_ncm
dwc2 1248.hsotg: Specified GNPTXFDEP=1024 > 768
dwc2 1248.hsotg: EPs: 16, dedicated fifos, 7808 entries in SPRAM
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-exynos: EHCI EXYNOS driver
exynos-ehci 1258.ehci: EHCI Host Controller
exynos-ehci 1258.ehci: new USB bus registered, assigned bus number 1
exynos-ehci 1258.ehci: irq 51, io mem 0x1258
exynos-ehci 1258.ehci: USB 2.0 started, EHCI 1.00
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 4.6.0-rc5-odroid ehci_hcd
usb usb1: SerialNumber: 1258.ehci
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci-exynos: OHCI EXYNOS driver
usbcore: registered new interface driver usb-storage
usb3503 0-0008: switched to HUB mode
usb3503 0-0008: usb3503_probe: probed in hub mode
using random self ethernet address
using random host ethernet address
usb0: HOST MAC 66:79:ef:11:72:85
usb0: MAC 1e:66:f2:66:8e:2a
using random self ethernet address
using random host ethernet address
g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
g_ether gadget: g_ether ready
dwc2 1248.hsotg: bound driver g_ether
mousedev: PS/2 mouse device common for all mice
max77686-rtc max77686-rtc: rtc core: registered max77686-rtc as rtc0
i2c /dev entries driver
s5p-fimc-md camera: Entity type for entity FIMC.0 was not initialized!
usb 1-2: new high-speed USB device number 2 using exynos-ehci
usb 1-2: New USB device found, idVendor=0424, idProduct=9730
usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
smsc95xx v1.0.4
smsc95xx 1-2:1.0 eth0: register 'smsc95xx' at usb-1258.ehci-2, smsc95xx
USB 2.0 Ethernet, c2:22:09:f2:5f:e8
usb 1-3: new high-speed USB device number 3 using exynos-ehci
usb 1-3: New USB device found, idVendor=0424, idProduct=3503
usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
hub 1-3:1.0: USB hub found
hub 1-3:1.0: 3 ports detected

No oops, no nothing. It's just sitting there.

Apparently you have encountered different issue. sysrq with 'l' might be
useful.


Is this a regression that was introduced in 4.6? Or is there some special
new config that needs to be turned on first in 4.6?

I think it was like that for looong time... although I did not use
netboot before on that target.

Sorry, I meant the hanging issue I got in 4.6, not the ethernet issue.
I get the same problem with linux-next. Can you mail me the .config you are 
using?

Never mind.


After 

Re: [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP booting

2016-05-01 Thread Krzysztof Kozlowski
On Sun, May 01, 2016 at 06:01:08PM +0200, Hans Verkuil wrote:
> > Sorry, I meant the hanging issue I got in 4.6, not the ethernet issue.
> > I get the same problem with linux-next. Can you mail me the .config you are 
> > using?
> 
> Never mind.
> 
> > After some more testing I don't think it is hanging, instead it seems that 
> > the mmc
> > isn't enabled/found and so it just sits waiting for the root partition to 
> > appear.
> 
> That was fun. There are two problems that both caused the boot to end at the 
> same
> place: first of all the root partition is now called mmcblk1p1 instead of 
> mmcblk0p1
> in 4.6, so it was just waiting for the root partition to appear. Nothing to 
> do with
> your patch series, just unexpected.

Yes, annoying issue and unfortunately this is known... recommended
solution is to use root=PARTUUID= (you can get the PARTUUID with
blkid)... or replace the mmc device.

> The second is that enabling CONFIG_VIDEO_S5P_FIMC causes the boot to hang at 
> that
> same place. I suspect there is a deadlock somewhere. I'm digging deeper into 
> that
> but again, unrelated to your patch series.
> 
> Anyway, after disabling that config option I was finally able to test your 
> patch
> series:
> 
> Tested-by: Hans Verkuil 

Thanks!

Best regards,
Krzysztof


Re: [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP booting

2016-05-01 Thread Krzysztof Kozlowski
On Sun, May 01, 2016 at 06:01:08PM +0200, Hans Verkuil wrote:
> > Sorry, I meant the hanging issue I got in 4.6, not the ethernet issue.
> > I get the same problem with linux-next. Can you mail me the .config you are 
> > using?
> 
> Never mind.
> 
> > After some more testing I don't think it is hanging, instead it seems that 
> > the mmc
> > isn't enabled/found and so it just sits waiting for the root partition to 
> > appear.
> 
> That was fun. There are two problems that both caused the boot to end at the 
> same
> place: first of all the root partition is now called mmcblk1p1 instead of 
> mmcblk0p1
> in 4.6, so it was just waiting for the root partition to appear. Nothing to 
> do with
> your patch series, just unexpected.

Yes, annoying issue and unfortunately this is known... recommended
solution is to use root=PARTUUID= (you can get the PARTUUID with
blkid)... or replace the mmc device.

> The second is that enabling CONFIG_VIDEO_S5P_FIMC causes the boot to hang at 
> that
> same place. I suspect there is a deadlock somewhere. I'm digging deeper into 
> that
> but again, unrelated to your patch series.
> 
> Anyway, after disabling that config option I was finally able to test your 
> patch
> series:
> 
> Tested-by: Hans Verkuil 

Thanks!

Best regards,
Krzysztof


Re: [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP booting

2016-05-01 Thread Hans Verkuil
On 05/01/2016 04:09 PM, Hans Verkuil wrote:
> On 05/01/2016 03:17 PM, Krzysztof Kozlowski wrote:
>> On Sat, Apr 30, 2016 at 11:43:44AM +0200, Hans Verkuil wrote:
>>> Hi Krzysztof,
>>>
>>> On 04/29/2016 12:59 PM, Krzysztof Kozlowski wrote:
 Hi,

 Patches are independent, please pick up as you wish.

 However all of them are needed to solve the issue, so I am sending
 everything together for easier testng.


 Problem
 ===
 When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
 the usb3503 does not show up in "lsusb". Hard-reset is required, e.g.
 by suspend to RAM. The actual TFTP boot does not have to happen. Just
 "usb start" from U-Boot is sufficient.


 Solution
 
 Perform real hardware reset (including regulator off/on) when probing.


 Tested on Odroid U3 so far. Please kindly test on X2 and other
 configurations and bootloaders.
>>>
>>> Against which kernel git repo is this patch?
>>>
>>> I did apply this patch series first:
>>>
>>> http://www.spinics.net/lists/arm-kernel/msg500764.html
>>
>> Indeed it is based on above patchset... and on linux-next. It touches
>> multiple trees so next seems the easiest base.
>>
>>>
>>> followed by this patch series.
>>>
>>> I've tested with both 4.6.0-rc2 and -rc5, but in all cases (even without
>>> applying these patches!) the boot sequence hangs here:
>>>
>>> ...
>>> [drm] Exynos DRM: using 12c1.mixer device for DMA mapping operations
>>> exynos-drm exynos-drm: bound 12c1.mixer (ops mixer_component_ops)
>>> exynos-drm exynos-drm: bound 12d0.hdmi (ops hdmi_component_ops)
>>> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>>> [drm] No driver support for vblank timestamp query.
>>> Console: switching to colour frame buffer device 240x67
>>> exynos-drm exynos-drm: fb0:  frame buffer device
>>> [drm] Initialized exynos 1.0.0 20110530 on minor 0
>>> brd: module loaded
>>> loop: module loaded
>>> s3c64xx-spi 1393.spi: spi bus clock parent not specified, using clock
>>> at index 0 as parent
>>> s3c64xx-spi 1393.spi: number of chip select lines not specified,
>>> assuming 1 chip select line
>>> tun: Universal TUN/TAP device driver, 1.6
>>> tun: (C) 1999-2004 Max Krasnyansky 
>>> usbcore: registered new interface driver asix
>>> usbcore: registered new interface driver ax88179_178a
>>> usbcore: registered new interface driver cdc_ether
>>> usbcore: registered new interface driver smsc95xx
>>> usbcore: registered new interface driver cdc_ncm
>>> dwc2 1248.hsotg: Specified GNPTXFDEP=1024 > 768
>>> dwc2 1248.hsotg: EPs: 16, dedicated fifos, 7808 entries in SPRAM
>>> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
>>> ehci-exynos: EHCI EXYNOS driver
>>> exynos-ehci 1258.ehci: EHCI Host Controller
>>> exynos-ehci 1258.ehci: new USB bus registered, assigned bus number 1
>>> exynos-ehci 1258.ehci: irq 51, io mem 0x1258
>>> exynos-ehci 1258.ehci: USB 2.0 started, EHCI 1.00
>>> usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
>>> usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
>>> usb usb1: Product: EHCI Host Controller
>>> usb usb1: Manufacturer: Linux 4.6.0-rc5-odroid ehci_hcd
>>> usb usb1: SerialNumber: 1258.ehci
>>> hub 1-0:1.0: USB hub found
>>> hub 1-0:1.0: 3 ports detected
>>> ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
>>> ohci-exynos: OHCI EXYNOS driver
>>> usbcore: registered new interface driver usb-storage
>>> usb3503 0-0008: switched to HUB mode
>>> usb3503 0-0008: usb3503_probe: probed in hub mode
>>> using random self ethernet address
>>> using random host ethernet address
>>> usb0: HOST MAC 66:79:ef:11:72:85
>>> usb0: MAC 1e:66:f2:66:8e:2a
>>> using random self ethernet address
>>> using random host ethernet address
>>> g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
>>> g_ether gadget: g_ether ready
>>> dwc2 1248.hsotg: bound driver g_ether
>>> mousedev: PS/2 mouse device common for all mice
>>> max77686-rtc max77686-rtc: rtc core: registered max77686-rtc as rtc0
>>> i2c /dev entries driver
>>> s5p-fimc-md camera: Entity type for entity FIMC.0 was not initialized!
>>> usb 1-2: new high-speed USB device number 2 using exynos-ehci
>>> usb 1-2: New USB device found, idVendor=0424, idProduct=9730
>>> usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
>>> smsc95xx v1.0.4
>>> smsc95xx 1-2:1.0 eth0: register 'smsc95xx' at usb-1258.ehci-2, smsc95xx
>>> USB 2.0 Ethernet, c2:22:09:f2:5f:e8
>>> usb 1-3: new high-speed USB device number 3 using exynos-ehci
>>> usb 1-3: New USB device found, idVendor=0424, idProduct=3503
>>> usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
>>> hub 1-3:1.0: USB hub found
>>> hub 1-3:1.0: 3 ports detected
>>>
>>> No oops, no nothing. It's just sitting there.
>>
>> Apparently you have encountered different issue. sysrq with 'l' might be
>> 

Re: [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP booting

2016-05-01 Thread Hans Verkuil
On 05/01/2016 04:09 PM, Hans Verkuil wrote:
> On 05/01/2016 03:17 PM, Krzysztof Kozlowski wrote:
>> On Sat, Apr 30, 2016 at 11:43:44AM +0200, Hans Verkuil wrote:
>>> Hi Krzysztof,
>>>
>>> On 04/29/2016 12:59 PM, Krzysztof Kozlowski wrote:
 Hi,

 Patches are independent, please pick up as you wish.

 However all of them are needed to solve the issue, so I am sending
 everything together for easier testng.


 Problem
 ===
 When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
 the usb3503 does not show up in "lsusb". Hard-reset is required, e.g.
 by suspend to RAM. The actual TFTP boot does not have to happen. Just
 "usb start" from U-Boot is sufficient.


 Solution
 
 Perform real hardware reset (including regulator off/on) when probing.


 Tested on Odroid U3 so far. Please kindly test on X2 and other
 configurations and bootloaders.
>>>
>>> Against which kernel git repo is this patch?
>>>
>>> I did apply this patch series first:
>>>
>>> http://www.spinics.net/lists/arm-kernel/msg500764.html
>>
>> Indeed it is based on above patchset... and on linux-next. It touches
>> multiple trees so next seems the easiest base.
>>
>>>
>>> followed by this patch series.
>>>
>>> I've tested with both 4.6.0-rc2 and -rc5, but in all cases (even without
>>> applying these patches!) the boot sequence hangs here:
>>>
>>> ...
>>> [drm] Exynos DRM: using 12c1.mixer device for DMA mapping operations
>>> exynos-drm exynos-drm: bound 12c1.mixer (ops mixer_component_ops)
>>> exynos-drm exynos-drm: bound 12d0.hdmi (ops hdmi_component_ops)
>>> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>>> [drm] No driver support for vblank timestamp query.
>>> Console: switching to colour frame buffer device 240x67
>>> exynos-drm exynos-drm: fb0:  frame buffer device
>>> [drm] Initialized exynos 1.0.0 20110530 on minor 0
>>> brd: module loaded
>>> loop: module loaded
>>> s3c64xx-spi 1393.spi: spi bus clock parent not specified, using clock
>>> at index 0 as parent
>>> s3c64xx-spi 1393.spi: number of chip select lines not specified,
>>> assuming 1 chip select line
>>> tun: Universal TUN/TAP device driver, 1.6
>>> tun: (C) 1999-2004 Max Krasnyansky 
>>> usbcore: registered new interface driver asix
>>> usbcore: registered new interface driver ax88179_178a
>>> usbcore: registered new interface driver cdc_ether
>>> usbcore: registered new interface driver smsc95xx
>>> usbcore: registered new interface driver cdc_ncm
>>> dwc2 1248.hsotg: Specified GNPTXFDEP=1024 > 768
>>> dwc2 1248.hsotg: EPs: 16, dedicated fifos, 7808 entries in SPRAM
>>> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
>>> ehci-exynos: EHCI EXYNOS driver
>>> exynos-ehci 1258.ehci: EHCI Host Controller
>>> exynos-ehci 1258.ehci: new USB bus registered, assigned bus number 1
>>> exynos-ehci 1258.ehci: irq 51, io mem 0x1258
>>> exynos-ehci 1258.ehci: USB 2.0 started, EHCI 1.00
>>> usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
>>> usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
>>> usb usb1: Product: EHCI Host Controller
>>> usb usb1: Manufacturer: Linux 4.6.0-rc5-odroid ehci_hcd
>>> usb usb1: SerialNumber: 1258.ehci
>>> hub 1-0:1.0: USB hub found
>>> hub 1-0:1.0: 3 ports detected
>>> ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
>>> ohci-exynos: OHCI EXYNOS driver
>>> usbcore: registered new interface driver usb-storage
>>> usb3503 0-0008: switched to HUB mode
>>> usb3503 0-0008: usb3503_probe: probed in hub mode
>>> using random self ethernet address
>>> using random host ethernet address
>>> usb0: HOST MAC 66:79:ef:11:72:85
>>> usb0: MAC 1e:66:f2:66:8e:2a
>>> using random self ethernet address
>>> using random host ethernet address
>>> g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
>>> g_ether gadget: g_ether ready
>>> dwc2 1248.hsotg: bound driver g_ether
>>> mousedev: PS/2 mouse device common for all mice
>>> max77686-rtc max77686-rtc: rtc core: registered max77686-rtc as rtc0
>>> i2c /dev entries driver
>>> s5p-fimc-md camera: Entity type for entity FIMC.0 was not initialized!
>>> usb 1-2: new high-speed USB device number 2 using exynos-ehci
>>> usb 1-2: New USB device found, idVendor=0424, idProduct=9730
>>> usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
>>> smsc95xx v1.0.4
>>> smsc95xx 1-2:1.0 eth0: register 'smsc95xx' at usb-1258.ehci-2, smsc95xx
>>> USB 2.0 Ethernet, c2:22:09:f2:5f:e8
>>> usb 1-3: new high-speed USB device number 3 using exynos-ehci
>>> usb 1-3: New USB device found, idVendor=0424, idProduct=3503
>>> usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
>>> hub 1-3:1.0: USB hub found
>>> hub 1-3:1.0: 3 ports detected
>>>
>>> No oops, no nothing. It's just sitting there.
>>
>> Apparently you have encountered different issue. sysrq with 'l' might be
>> useful.
>>
>>> Is 

Re: [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP booting

2016-05-01 Thread Hans Verkuil
On 05/01/2016 03:17 PM, Krzysztof Kozlowski wrote:
> On Sat, Apr 30, 2016 at 11:43:44AM +0200, Hans Verkuil wrote:
>> Hi Krzysztof,
>>
>> On 04/29/2016 12:59 PM, Krzysztof Kozlowski wrote:
>>> Hi,
>>>
>>> Patches are independent, please pick up as you wish.
>>>
>>> However all of them are needed to solve the issue, so I am sending
>>> everything together for easier testng.
>>>
>>>
>>> Problem
>>> ===
>>> When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
>>> the usb3503 does not show up in "lsusb". Hard-reset is required, e.g.
>>> by suspend to RAM. The actual TFTP boot does not have to happen. Just
>>> "usb start" from U-Boot is sufficient.
>>>
>>>
>>> Solution
>>> 
>>> Perform real hardware reset (including regulator off/on) when probing.
>>>
>>>
>>> Tested on Odroid U3 so far. Please kindly test on X2 and other
>>> configurations and bootloaders.
>>
>> Against which kernel git repo is this patch?
>>
>> I did apply this patch series first:
>>
>> http://www.spinics.net/lists/arm-kernel/msg500764.html
> 
> Indeed it is based on above patchset... and on linux-next. It touches
> multiple trees so next seems the easiest base.
> 
>>
>> followed by this patch series.
>>
>> I've tested with both 4.6.0-rc2 and -rc5, but in all cases (even without
>> applying these patches!) the boot sequence hangs here:
>>
>> ...
>> [drm] Exynos DRM: using 12c1.mixer device for DMA mapping operations
>> exynos-drm exynos-drm: bound 12c1.mixer (ops mixer_component_ops)
>> exynos-drm exynos-drm: bound 12d0.hdmi (ops hdmi_component_ops)
>> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> [drm] No driver support for vblank timestamp query.
>> Console: switching to colour frame buffer device 240x67
>> exynos-drm exynos-drm: fb0:  frame buffer device
>> [drm] Initialized exynos 1.0.0 20110530 on minor 0
>> brd: module loaded
>> loop: module loaded
>> s3c64xx-spi 1393.spi: spi bus clock parent not specified, using clock
>> at index 0 as parent
>> s3c64xx-spi 1393.spi: number of chip select lines not specified,
>> assuming 1 chip select line
>> tun: Universal TUN/TAP device driver, 1.6
>> tun: (C) 1999-2004 Max Krasnyansky 
>> usbcore: registered new interface driver asix
>> usbcore: registered new interface driver ax88179_178a
>> usbcore: registered new interface driver cdc_ether
>> usbcore: registered new interface driver smsc95xx
>> usbcore: registered new interface driver cdc_ncm
>> dwc2 1248.hsotg: Specified GNPTXFDEP=1024 > 768
>> dwc2 1248.hsotg: EPs: 16, dedicated fifos, 7808 entries in SPRAM
>> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
>> ehci-exynos: EHCI EXYNOS driver
>> exynos-ehci 1258.ehci: EHCI Host Controller
>> exynos-ehci 1258.ehci: new USB bus registered, assigned bus number 1
>> exynos-ehci 1258.ehci: irq 51, io mem 0x1258
>> exynos-ehci 1258.ehci: USB 2.0 started, EHCI 1.00
>> usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
>> usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
>> usb usb1: Product: EHCI Host Controller
>> usb usb1: Manufacturer: Linux 4.6.0-rc5-odroid ehci_hcd
>> usb usb1: SerialNumber: 1258.ehci
>> hub 1-0:1.0: USB hub found
>> hub 1-0:1.0: 3 ports detected
>> ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
>> ohci-exynos: OHCI EXYNOS driver
>> usbcore: registered new interface driver usb-storage
>> usb3503 0-0008: switched to HUB mode
>> usb3503 0-0008: usb3503_probe: probed in hub mode
>> using random self ethernet address
>> using random host ethernet address
>> usb0: HOST MAC 66:79:ef:11:72:85
>> usb0: MAC 1e:66:f2:66:8e:2a
>> using random self ethernet address
>> using random host ethernet address
>> g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
>> g_ether gadget: g_ether ready
>> dwc2 1248.hsotg: bound driver g_ether
>> mousedev: PS/2 mouse device common for all mice
>> max77686-rtc max77686-rtc: rtc core: registered max77686-rtc as rtc0
>> i2c /dev entries driver
>> s5p-fimc-md camera: Entity type for entity FIMC.0 was not initialized!
>> usb 1-2: new high-speed USB device number 2 using exynos-ehci
>> usb 1-2: New USB device found, idVendor=0424, idProduct=9730
>> usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
>> smsc95xx v1.0.4
>> smsc95xx 1-2:1.0 eth0: register 'smsc95xx' at usb-1258.ehci-2, smsc95xx
>> USB 2.0 Ethernet, c2:22:09:f2:5f:e8
>> usb 1-3: new high-speed USB device number 3 using exynos-ehci
>> usb 1-3: New USB device found, idVendor=0424, idProduct=3503
>> usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
>> hub 1-3:1.0: USB hub found
>> hub 1-3:1.0: 3 ports detected
>>
>> No oops, no nothing. It's just sitting there.
> 
> Apparently you have encountered different issue. sysrq with 'l' might be
> useful.
> 
>> Is this a regression that was introduced in 4.6? Or is there some special
>> new config that needs to be turned on first in 4.6?
> 
> I think 

Re: [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP booting

2016-05-01 Thread Hans Verkuil
On 05/01/2016 03:17 PM, Krzysztof Kozlowski wrote:
> On Sat, Apr 30, 2016 at 11:43:44AM +0200, Hans Verkuil wrote:
>> Hi Krzysztof,
>>
>> On 04/29/2016 12:59 PM, Krzysztof Kozlowski wrote:
>>> Hi,
>>>
>>> Patches are independent, please pick up as you wish.
>>>
>>> However all of them are needed to solve the issue, so I am sending
>>> everything together for easier testng.
>>>
>>>
>>> Problem
>>> ===
>>> When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
>>> the usb3503 does not show up in "lsusb". Hard-reset is required, e.g.
>>> by suspend to RAM. The actual TFTP boot does not have to happen. Just
>>> "usb start" from U-Boot is sufficient.
>>>
>>>
>>> Solution
>>> 
>>> Perform real hardware reset (including regulator off/on) when probing.
>>>
>>>
>>> Tested on Odroid U3 so far. Please kindly test on X2 and other
>>> configurations and bootloaders.
>>
>> Against which kernel git repo is this patch?
>>
>> I did apply this patch series first:
>>
>> http://www.spinics.net/lists/arm-kernel/msg500764.html
> 
> Indeed it is based on above patchset... and on linux-next. It touches
> multiple trees so next seems the easiest base.
> 
>>
>> followed by this patch series.
>>
>> I've tested with both 4.6.0-rc2 and -rc5, but in all cases (even without
>> applying these patches!) the boot sequence hangs here:
>>
>> ...
>> [drm] Exynos DRM: using 12c1.mixer device for DMA mapping operations
>> exynos-drm exynos-drm: bound 12c1.mixer (ops mixer_component_ops)
>> exynos-drm exynos-drm: bound 12d0.hdmi (ops hdmi_component_ops)
>> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> [drm] No driver support for vblank timestamp query.
>> Console: switching to colour frame buffer device 240x67
>> exynos-drm exynos-drm: fb0:  frame buffer device
>> [drm] Initialized exynos 1.0.0 20110530 on minor 0
>> brd: module loaded
>> loop: module loaded
>> s3c64xx-spi 1393.spi: spi bus clock parent not specified, using clock
>> at index 0 as parent
>> s3c64xx-spi 1393.spi: number of chip select lines not specified,
>> assuming 1 chip select line
>> tun: Universal TUN/TAP device driver, 1.6
>> tun: (C) 1999-2004 Max Krasnyansky 
>> usbcore: registered new interface driver asix
>> usbcore: registered new interface driver ax88179_178a
>> usbcore: registered new interface driver cdc_ether
>> usbcore: registered new interface driver smsc95xx
>> usbcore: registered new interface driver cdc_ncm
>> dwc2 1248.hsotg: Specified GNPTXFDEP=1024 > 768
>> dwc2 1248.hsotg: EPs: 16, dedicated fifos, 7808 entries in SPRAM
>> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
>> ehci-exynos: EHCI EXYNOS driver
>> exynos-ehci 1258.ehci: EHCI Host Controller
>> exynos-ehci 1258.ehci: new USB bus registered, assigned bus number 1
>> exynos-ehci 1258.ehci: irq 51, io mem 0x1258
>> exynos-ehci 1258.ehci: USB 2.0 started, EHCI 1.00
>> usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
>> usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
>> usb usb1: Product: EHCI Host Controller
>> usb usb1: Manufacturer: Linux 4.6.0-rc5-odroid ehci_hcd
>> usb usb1: SerialNumber: 1258.ehci
>> hub 1-0:1.0: USB hub found
>> hub 1-0:1.0: 3 ports detected
>> ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
>> ohci-exynos: OHCI EXYNOS driver
>> usbcore: registered new interface driver usb-storage
>> usb3503 0-0008: switched to HUB mode
>> usb3503 0-0008: usb3503_probe: probed in hub mode
>> using random self ethernet address
>> using random host ethernet address
>> usb0: HOST MAC 66:79:ef:11:72:85
>> usb0: MAC 1e:66:f2:66:8e:2a
>> using random self ethernet address
>> using random host ethernet address
>> g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
>> g_ether gadget: g_ether ready
>> dwc2 1248.hsotg: bound driver g_ether
>> mousedev: PS/2 mouse device common for all mice
>> max77686-rtc max77686-rtc: rtc core: registered max77686-rtc as rtc0
>> i2c /dev entries driver
>> s5p-fimc-md camera: Entity type for entity FIMC.0 was not initialized!
>> usb 1-2: new high-speed USB device number 2 using exynos-ehci
>> usb 1-2: New USB device found, idVendor=0424, idProduct=9730
>> usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
>> smsc95xx v1.0.4
>> smsc95xx 1-2:1.0 eth0: register 'smsc95xx' at usb-1258.ehci-2, smsc95xx
>> USB 2.0 Ethernet, c2:22:09:f2:5f:e8
>> usb 1-3: new high-speed USB device number 3 using exynos-ehci
>> usb 1-3: New USB device found, idVendor=0424, idProduct=3503
>> usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
>> hub 1-3:1.0: USB hub found
>> hub 1-3:1.0: 3 ports detected
>>
>> No oops, no nothing. It's just sitting there.
> 
> Apparently you have encountered different issue. sysrq with 'l' might be
> useful.
> 
>> Is this a regression that was introduced in 4.6? Or is there some special
>> new config that needs to be turned on first in 4.6?
> 
> I think it was like that 

Re: [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP booting

2016-05-01 Thread Krzysztof Kozlowski
On Sat, Apr 30, 2016 at 11:43:44AM +0200, Hans Verkuil wrote:
> Hi Krzysztof,
> 
> On 04/29/2016 12:59 PM, Krzysztof Kozlowski wrote:
> > Hi,
> > 
> > Patches are independent, please pick up as you wish.
> > 
> > However all of them are needed to solve the issue, so I am sending
> > everything together for easier testng.
> > 
> > 
> > Problem
> > ===
> > When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
> > the usb3503 does not show up in "lsusb". Hard-reset is required, e.g.
> > by suspend to RAM. The actual TFTP boot does not have to happen. Just
> > "usb start" from U-Boot is sufficient.
> > 
> > 
> > Solution
> > 
> > Perform real hardware reset (including regulator off/on) when probing.
> > 
> > 
> > Tested on Odroid U3 so far. Please kindly test on X2 and other
> > configurations and bootloaders.
> 
> Against which kernel git repo is this patch?
> 
> I did apply this patch series first:
> 
> http://www.spinics.net/lists/arm-kernel/msg500764.html

Indeed it is based on above patchset... and on linux-next. It touches
multiple trees so next seems the easiest base.

> 
> followed by this patch series.
> 
> I've tested with both 4.6.0-rc2 and -rc5, but in all cases (even without
> applying these patches!) the boot sequence hangs here:
> 
> ...
> [drm] Exynos DRM: using 12c1.mixer device for DMA mapping operations
> exynos-drm exynos-drm: bound 12c1.mixer (ops mixer_component_ops)
> exynos-drm exynos-drm: bound 12d0.hdmi (ops hdmi_component_ops)
> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [drm] No driver support for vblank timestamp query.
> Console: switching to colour frame buffer device 240x67
> exynos-drm exynos-drm: fb0:  frame buffer device
> [drm] Initialized exynos 1.0.0 20110530 on minor 0
> brd: module loaded
> loop: module loaded
> s3c64xx-spi 1393.spi: spi bus clock parent not specified, using clock
> at index 0 as parent
> s3c64xx-spi 1393.spi: number of chip select lines not specified,
> assuming 1 chip select line
> tun: Universal TUN/TAP device driver, 1.6
> tun: (C) 1999-2004 Max Krasnyansky 
> usbcore: registered new interface driver asix
> usbcore: registered new interface driver ax88179_178a
> usbcore: registered new interface driver cdc_ether
> usbcore: registered new interface driver smsc95xx
> usbcore: registered new interface driver cdc_ncm
> dwc2 1248.hsotg: Specified GNPTXFDEP=1024 > 768
> dwc2 1248.hsotg: EPs: 16, dedicated fifos, 7808 entries in SPRAM
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> ehci-exynos: EHCI EXYNOS driver
> exynos-ehci 1258.ehci: EHCI Host Controller
> exynos-ehci 1258.ehci: new USB bus registered, assigned bus number 1
> exynos-ehci 1258.ehci: irq 51, io mem 0x1258
> exynos-ehci 1258.ehci: USB 2.0 started, EHCI 1.00
> usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
> usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> usb usb1: Product: EHCI Host Controller
> usb usb1: Manufacturer: Linux 4.6.0-rc5-odroid ehci_hcd
> usb usb1: SerialNumber: 1258.ehci
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 3 ports detected
> ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> ohci-exynos: OHCI EXYNOS driver
> usbcore: registered new interface driver usb-storage
> usb3503 0-0008: switched to HUB mode
> usb3503 0-0008: usb3503_probe: probed in hub mode
> using random self ethernet address
> using random host ethernet address
> usb0: HOST MAC 66:79:ef:11:72:85
> usb0: MAC 1e:66:f2:66:8e:2a
> using random self ethernet address
> using random host ethernet address
> g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
> g_ether gadget: g_ether ready
> dwc2 1248.hsotg: bound driver g_ether
> mousedev: PS/2 mouse device common for all mice
> max77686-rtc max77686-rtc: rtc core: registered max77686-rtc as rtc0
> i2c /dev entries driver
> s5p-fimc-md camera: Entity type for entity FIMC.0 was not initialized!
> usb 1-2: new high-speed USB device number 2 using exynos-ehci
> usb 1-2: New USB device found, idVendor=0424, idProduct=9730
> usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> smsc95xx v1.0.4
> smsc95xx 1-2:1.0 eth0: register 'smsc95xx' at usb-1258.ehci-2, smsc95xx
> USB 2.0 Ethernet, c2:22:09:f2:5f:e8
> usb 1-3: new high-speed USB device number 3 using exynos-ehci
> usb 1-3: New USB device found, idVendor=0424, idProduct=3503
> usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> hub 1-3:1.0: USB hub found
> hub 1-3:1.0: 3 ports detected
> 
> No oops, no nothing. It's just sitting there.

Apparently you have encountered different issue. sysrq with 'l' might be
useful.

> Is this a regression that was introduced in 4.6? Or is there some special
> new config that needs to be turned on first in 4.6?

I think it was like that for looong time... although I did not use
netboot before on that target.

> I've been running
> 4.5.0-rc3 before this, but I 

Re: [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP booting

2016-05-01 Thread Krzysztof Kozlowski
On Sat, Apr 30, 2016 at 11:43:44AM +0200, Hans Verkuil wrote:
> Hi Krzysztof,
> 
> On 04/29/2016 12:59 PM, Krzysztof Kozlowski wrote:
> > Hi,
> > 
> > Patches are independent, please pick up as you wish.
> > 
> > However all of them are needed to solve the issue, so I am sending
> > everything together for easier testng.
> > 
> > 
> > Problem
> > ===
> > When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
> > the usb3503 does not show up in "lsusb". Hard-reset is required, e.g.
> > by suspend to RAM. The actual TFTP boot does not have to happen. Just
> > "usb start" from U-Boot is sufficient.
> > 
> > 
> > Solution
> > 
> > Perform real hardware reset (including regulator off/on) when probing.
> > 
> > 
> > Tested on Odroid U3 so far. Please kindly test on X2 and other
> > configurations and bootloaders.
> 
> Against which kernel git repo is this patch?
> 
> I did apply this patch series first:
> 
> http://www.spinics.net/lists/arm-kernel/msg500764.html

Indeed it is based on above patchset... and on linux-next. It touches
multiple trees so next seems the easiest base.

> 
> followed by this patch series.
> 
> I've tested with both 4.6.0-rc2 and -rc5, but in all cases (even without
> applying these patches!) the boot sequence hangs here:
> 
> ...
> [drm] Exynos DRM: using 12c1.mixer device for DMA mapping operations
> exynos-drm exynos-drm: bound 12c1.mixer (ops mixer_component_ops)
> exynos-drm exynos-drm: bound 12d0.hdmi (ops hdmi_component_ops)
> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [drm] No driver support for vblank timestamp query.
> Console: switching to colour frame buffer device 240x67
> exynos-drm exynos-drm: fb0:  frame buffer device
> [drm] Initialized exynos 1.0.0 20110530 on minor 0
> brd: module loaded
> loop: module loaded
> s3c64xx-spi 1393.spi: spi bus clock parent not specified, using clock
> at index 0 as parent
> s3c64xx-spi 1393.spi: number of chip select lines not specified,
> assuming 1 chip select line
> tun: Universal TUN/TAP device driver, 1.6
> tun: (C) 1999-2004 Max Krasnyansky 
> usbcore: registered new interface driver asix
> usbcore: registered new interface driver ax88179_178a
> usbcore: registered new interface driver cdc_ether
> usbcore: registered new interface driver smsc95xx
> usbcore: registered new interface driver cdc_ncm
> dwc2 1248.hsotg: Specified GNPTXFDEP=1024 > 768
> dwc2 1248.hsotg: EPs: 16, dedicated fifos, 7808 entries in SPRAM
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> ehci-exynos: EHCI EXYNOS driver
> exynos-ehci 1258.ehci: EHCI Host Controller
> exynos-ehci 1258.ehci: new USB bus registered, assigned bus number 1
> exynos-ehci 1258.ehci: irq 51, io mem 0x1258
> exynos-ehci 1258.ehci: USB 2.0 started, EHCI 1.00
> usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
> usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> usb usb1: Product: EHCI Host Controller
> usb usb1: Manufacturer: Linux 4.6.0-rc5-odroid ehci_hcd
> usb usb1: SerialNumber: 1258.ehci
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 3 ports detected
> ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> ohci-exynos: OHCI EXYNOS driver
> usbcore: registered new interface driver usb-storage
> usb3503 0-0008: switched to HUB mode
> usb3503 0-0008: usb3503_probe: probed in hub mode
> using random self ethernet address
> using random host ethernet address
> usb0: HOST MAC 66:79:ef:11:72:85
> usb0: MAC 1e:66:f2:66:8e:2a
> using random self ethernet address
> using random host ethernet address
> g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
> g_ether gadget: g_ether ready
> dwc2 1248.hsotg: bound driver g_ether
> mousedev: PS/2 mouse device common for all mice
> max77686-rtc max77686-rtc: rtc core: registered max77686-rtc as rtc0
> i2c /dev entries driver
> s5p-fimc-md camera: Entity type for entity FIMC.0 was not initialized!
> usb 1-2: new high-speed USB device number 2 using exynos-ehci
> usb 1-2: New USB device found, idVendor=0424, idProduct=9730
> usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> smsc95xx v1.0.4
> smsc95xx 1-2:1.0 eth0: register 'smsc95xx' at usb-1258.ehci-2, smsc95xx
> USB 2.0 Ethernet, c2:22:09:f2:5f:e8
> usb 1-3: new high-speed USB device number 3 using exynos-ehci
> usb 1-3: New USB device found, idVendor=0424, idProduct=3503
> usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> hub 1-3:1.0: USB hub found
> hub 1-3:1.0: 3 ports detected
> 
> No oops, no nothing. It's just sitting there.

Apparently you have encountered different issue. sysrq with 'l' might be
useful.

> Is this a regression that was introduced in 4.6? Or is there some special
> new config that needs to be turned on first in 4.6?

I think it was like that for looong time... although I did not use
netboot before on that target.

> I've been running
> 4.5.0-rc3 before this, but I can't apply these 

Re: [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP booting

2016-04-30 Thread Hans Verkuil
Hi Krzysztof,

On 04/29/2016 12:59 PM, Krzysztof Kozlowski wrote:
> Hi,
> 
> Patches are independent, please pick up as you wish.
> 
> However all of them are needed to solve the issue, so I am sending
> everything together for easier testng.
> 
> 
> Problem
> ===
> When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
> the usb3503 does not show up in "lsusb". Hard-reset is required, e.g.
> by suspend to RAM. The actual TFTP boot does not have to happen. Just
> "usb start" from U-Boot is sufficient.
> 
> 
> Solution
> 
> Perform real hardware reset (including regulator off/on) when probing.
> 
> 
> Tested on Odroid U3 so far. Please kindly test on X2 and other
> configurations and bootloaders.

Against which kernel git repo is this patch?

I did apply this patch series first:

http://www.spinics.net/lists/arm-kernel/msg500764.html

followed by this patch series.

I've tested with both 4.6.0-rc2 and -rc5, but in all cases (even without
applying these patches!) the boot sequence hangs here:

...
[drm] Exynos DRM: using 12c1.mixer device for DMA mapping operations
exynos-drm exynos-drm: bound 12c1.mixer (ops mixer_component_ops)
exynos-drm exynos-drm: bound 12d0.hdmi (ops hdmi_component_ops)
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.
Console: switching to colour frame buffer device 240x67
exynos-drm exynos-drm: fb0:  frame buffer device
[drm] Initialized exynos 1.0.0 20110530 on minor 0
brd: module loaded
loop: module loaded
s3c64xx-spi 1393.spi: spi bus clock parent not specified, using clock
at index 0 as parent
s3c64xx-spi 1393.spi: number of chip select lines not specified,
assuming 1 chip select line
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky 
usbcore: registered new interface driver asix
usbcore: registered new interface driver ax88179_178a
usbcore: registered new interface driver cdc_ether
usbcore: registered new interface driver smsc95xx
usbcore: registered new interface driver cdc_ncm
dwc2 1248.hsotg: Specified GNPTXFDEP=1024 > 768
dwc2 1248.hsotg: EPs: 16, dedicated fifos, 7808 entries in SPRAM
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-exynos: EHCI EXYNOS driver
exynos-ehci 1258.ehci: EHCI Host Controller
exynos-ehci 1258.ehci: new USB bus registered, assigned bus number 1
exynos-ehci 1258.ehci: irq 51, io mem 0x1258
exynos-ehci 1258.ehci: USB 2.0 started, EHCI 1.00
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 4.6.0-rc5-odroid ehci_hcd
usb usb1: SerialNumber: 1258.ehci
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci-exynos: OHCI EXYNOS driver
usbcore: registered new interface driver usb-storage
usb3503 0-0008: switched to HUB mode
usb3503 0-0008: usb3503_probe: probed in hub mode
using random self ethernet address
using random host ethernet address
usb0: HOST MAC 66:79:ef:11:72:85
usb0: MAC 1e:66:f2:66:8e:2a
using random self ethernet address
using random host ethernet address
g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
g_ether gadget: g_ether ready
dwc2 1248.hsotg: bound driver g_ether
mousedev: PS/2 mouse device common for all mice
max77686-rtc max77686-rtc: rtc core: registered max77686-rtc as rtc0
i2c /dev entries driver
s5p-fimc-md camera: Entity type for entity FIMC.0 was not initialized!
usb 1-2: new high-speed USB device number 2 using exynos-ehci
usb 1-2: New USB device found, idVendor=0424, idProduct=9730
usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
smsc95xx v1.0.4
smsc95xx 1-2:1.0 eth0: register 'smsc95xx' at usb-1258.ehci-2, smsc95xx
USB 2.0 Ethernet, c2:22:09:f2:5f:e8
usb 1-3: new high-speed USB device number 3 using exynos-ehci
usb 1-3: New USB device found, idVendor=0424, idProduct=3503
usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
hub 1-3:1.0: USB hub found
hub 1-3:1.0: 3 ports detected

No oops, no nothing. It's just sitting there.

Is this a regression that was introduced in 4.6? Or is there some special
new config that needs to be turned on first in 4.6? I've been running
4.5.0-rc3 before this, but I can't apply these patches there because there
is no drivers/regulator/max77686-regulator.c in 4.5.

Regards,

Hans

> 
> 
> Best regards,
> Krzysztof
> 
> Krzysztof Kozlowski (3):
>   usb: misc: usb3503: Fix HUB mode after bootloader initialization
>   ARM: dts: exynos: Provide regulator for usb3503 on Odroid to fix
> device detection
>   regulator: max77686: Configure enable time to properly handle
> regulator enable
> 
>  Documentation/devicetree/bindings/usb/usb3503.txt |  1 +
>  arch/arm/boot/dts/exynos4412-odroidu3.dts |  2 +
>  

Re: [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP booting

2016-04-30 Thread Hans Verkuil
Hi Krzysztof,

On 04/29/2016 12:59 PM, Krzysztof Kozlowski wrote:
> Hi,
> 
> Patches are independent, please pick up as you wish.
> 
> However all of them are needed to solve the issue, so I am sending
> everything together for easier testng.
> 
> 
> Problem
> ===
> When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
> the usb3503 does not show up in "lsusb". Hard-reset is required, e.g.
> by suspend to RAM. The actual TFTP boot does not have to happen. Just
> "usb start" from U-Boot is sufficient.
> 
> 
> Solution
> 
> Perform real hardware reset (including regulator off/on) when probing.
> 
> 
> Tested on Odroid U3 so far. Please kindly test on X2 and other
> configurations and bootloaders.

Against which kernel git repo is this patch?

I did apply this patch series first:

http://www.spinics.net/lists/arm-kernel/msg500764.html

followed by this patch series.

I've tested with both 4.6.0-rc2 and -rc5, but in all cases (even without
applying these patches!) the boot sequence hangs here:

...
[drm] Exynos DRM: using 12c1.mixer device for DMA mapping operations
exynos-drm exynos-drm: bound 12c1.mixer (ops mixer_component_ops)
exynos-drm exynos-drm: bound 12d0.hdmi (ops hdmi_component_ops)
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.
Console: switching to colour frame buffer device 240x67
exynos-drm exynos-drm: fb0:  frame buffer device
[drm] Initialized exynos 1.0.0 20110530 on minor 0
brd: module loaded
loop: module loaded
s3c64xx-spi 1393.spi: spi bus clock parent not specified, using clock
at index 0 as parent
s3c64xx-spi 1393.spi: number of chip select lines not specified,
assuming 1 chip select line
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky 
usbcore: registered new interface driver asix
usbcore: registered new interface driver ax88179_178a
usbcore: registered new interface driver cdc_ether
usbcore: registered new interface driver smsc95xx
usbcore: registered new interface driver cdc_ncm
dwc2 1248.hsotg: Specified GNPTXFDEP=1024 > 768
dwc2 1248.hsotg: EPs: 16, dedicated fifos, 7808 entries in SPRAM
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-exynos: EHCI EXYNOS driver
exynos-ehci 1258.ehci: EHCI Host Controller
exynos-ehci 1258.ehci: new USB bus registered, assigned bus number 1
exynos-ehci 1258.ehci: irq 51, io mem 0x1258
exynos-ehci 1258.ehci: USB 2.0 started, EHCI 1.00
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 4.6.0-rc5-odroid ehci_hcd
usb usb1: SerialNumber: 1258.ehci
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci-exynos: OHCI EXYNOS driver
usbcore: registered new interface driver usb-storage
usb3503 0-0008: switched to HUB mode
usb3503 0-0008: usb3503_probe: probed in hub mode
using random self ethernet address
using random host ethernet address
usb0: HOST MAC 66:79:ef:11:72:85
usb0: MAC 1e:66:f2:66:8e:2a
using random self ethernet address
using random host ethernet address
g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
g_ether gadget: g_ether ready
dwc2 1248.hsotg: bound driver g_ether
mousedev: PS/2 mouse device common for all mice
max77686-rtc max77686-rtc: rtc core: registered max77686-rtc as rtc0
i2c /dev entries driver
s5p-fimc-md camera: Entity type for entity FIMC.0 was not initialized!
usb 1-2: new high-speed USB device number 2 using exynos-ehci
usb 1-2: New USB device found, idVendor=0424, idProduct=9730
usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
smsc95xx v1.0.4
smsc95xx 1-2:1.0 eth0: register 'smsc95xx' at usb-1258.ehci-2, smsc95xx
USB 2.0 Ethernet, c2:22:09:f2:5f:e8
usb 1-3: new high-speed USB device number 3 using exynos-ehci
usb 1-3: New USB device found, idVendor=0424, idProduct=3503
usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
hub 1-3:1.0: USB hub found
hub 1-3:1.0: 3 ports detected

No oops, no nothing. It's just sitting there.

Is this a regression that was introduced in 4.6? Or is there some special
new config that needs to be turned on first in 4.6? I've been running
4.5.0-rc3 before this, but I can't apply these patches there because there
is no drivers/regulator/max77686-regulator.c in 4.5.

Regards,

Hans

> 
> 
> Best regards,
> Krzysztof
> 
> Krzysztof Kozlowski (3):
>   usb: misc: usb3503: Fix HUB mode after bootloader initialization
>   ARM: dts: exynos: Provide regulator for usb3503 on Odroid to fix
> device detection
>   regulator: max77686: Configure enable time to properly handle
> regulator enable
> 
>  Documentation/devicetree/bindings/usb/usb3503.txt |  1 +
>  arch/arm/boot/dts/exynos4412-odroidu3.dts |  2 +
>  drivers/regulator/max77686-regulator.c 

[RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP booting

2016-04-29 Thread Krzysztof Kozlowski
Hi,

Patches are independent, please pick up as you wish.

However all of them are needed to solve the issue, so I am sending
everything together for easier testng.


Problem
===
When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
the usb3503 does not show up in "lsusb". Hard-reset is required, e.g.
by suspend to RAM. The actual TFTP boot does not have to happen. Just
"usb start" from U-Boot is sufficient.


Solution

Perform real hardware reset (including regulator off/on) when probing.


Tested on Odroid U3 so far. Please kindly test on X2 and other
configurations and bootloaders.


Best regards,
Krzysztof

Krzysztof Kozlowski (3):
  usb: misc: usb3503: Fix HUB mode after bootloader initialization
  ARM: dts: exynos: Provide regulator for usb3503 on Odroid to fix
device detection
  regulator: max77686: Configure enable time to properly handle
regulator enable

 Documentation/devicetree/bindings/usb/usb3503.txt |  1 +
 arch/arm/boot/dts/exynos4412-odroidu3.dts |  2 +
 drivers/regulator/max77686-regulator.c|  5 ++
 drivers/usb/misc/usb3503.c| 81 +++
 4 files changed, 89 insertions(+)

-- 
1.9.1



[RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP booting

2016-04-29 Thread Krzysztof Kozlowski
Hi,

Patches are independent, please pick up as you wish.

However all of them are needed to solve the issue, so I am sending
everything together for easier testng.


Problem
===
When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
the usb3503 does not show up in "lsusb". Hard-reset is required, e.g.
by suspend to RAM. The actual TFTP boot does not have to happen. Just
"usb start" from U-Boot is sufficient.


Solution

Perform real hardware reset (including regulator off/on) when probing.


Tested on Odroid U3 so far. Please kindly test on X2 and other
configurations and bootloaders.


Best regards,
Krzysztof

Krzysztof Kozlowski (3):
  usb: misc: usb3503: Fix HUB mode after bootloader initialization
  ARM: dts: exynos: Provide regulator for usb3503 on Odroid to fix
device detection
  regulator: max77686: Configure enable time to properly handle
regulator enable

 Documentation/devicetree/bindings/usb/usb3503.txt |  1 +
 arch/arm/boot/dts/exynos4412-odroidu3.dts |  2 +
 drivers/regulator/max77686-regulator.c|  5 ++
 drivers/usb/misc/usb3503.c| 81 +++
 4 files changed, 89 insertions(+)

-- 
1.9.1