Re: [U-Boot] [PATCH v1 0/6] Introduce DCU support for Vybrid

[maitysanchayan]

Ping?

On 17-02-06 13:00:28, Sanchayan Maity wrote:
> Hello,
> 
> This patchset adds support for the Freescale/NXP Display
> Controller Unit (DCU4) found on the LS1021A and Vybrid
> SoC.
> 
> Patch series is based on top of latest u-boot master.
> 
> First patch in the series renames existing CONFIG_FSL_DCU_FB
> to CONFIG_VIDEO_FSL_DCU_FB and then converts it to Kconfig.
> All board defconfigs affected by this patch have been compile
> tested.
> 
> Patch 2-5 introduce incremental changes for supporting DCU
> on Vybrid.
> 
> Patch 6 in the series adds DCU support to Vybrid and has been
> tested on Toradex Colibri VF61 module.
> 
> Will appreciate it if the maintainers or users of LS1021 SoC
> can test this to check and report regressions if any.
> 
> Thanks & Regards,
> Sanchayan.
> 
> Sanchayan Maity (1):
>   Convert CONFIG_FSL_DCU_FB to Kconfig
> 
> Stefan Agner (5):
>   video: fsl_dcu_fb: fix framebuffer to the end of memory
>   video: fsl_dcu_fb: Enable pixel clock after initialization
>   video: fsl_dcu_fb: Update DCU layers for Vybrid
>   video: fsl_dcu_fb: add additional modes for DCU
>   board: toradex: colibri_vf: Add DCU support for Colibri Vybrid
> 
>  arch/arm/cpu/armv7/ls102xa/soc.c   |   2 +-
>  arch/arm/include/asm/arch-ls102xa/config.h |   1 +
>  arch/arm/include/asm/arch-vf610/crm_regs.h |  14 +++
>  arch/arm/include/asm/arch-vf610/imx-regs.h |   2 +
>  arch/arm/include/asm/arch-vf610/iomux-vf610.h  |  31 ++
>  arch/arm/include/asm/imx-common/iomux-v3.h |   3 +
>  board/freescale/ls1021aiot/Makefile|   2 +-
>  board/freescale/ls1021aqds/Makefile|   2 +-
>  board/freescale/ls1021atwr/Makefile|   2 +-
>  board/toradex/colibri_vf/Makefile  |   1 +
>  board/toradex/colibri_vf/colibri_vf.c  |  76 ++---
>  board/toradex/colibri_vf/dcu.c |  38 +++
>  configs/colibri_vf_defconfig   |   4 +
>  configs/ls1021aqds_ddr4_nor_defconfig  |   1 +
>  configs/ls1021aqds_ddr4_nor_lpuart_defconfig   |   1 +
>  configs/ls1021aqds_nand_defconfig  |   1 +
>  configs/ls1021aqds_nor_SECURE_BOOT_defconfig   |   1 +
>  configs/ls1021aqds_nor_defconfig   |   1 +
>  configs/ls1021aqds_nor_lpuart_defconfig|   1 +
>  configs/ls1021aqds_qspi_defconfig  |   1 +
>  configs/ls1021aqds_sdcard_ifc_defconfig|   1 +
>  configs/ls1021aqds_sdcard_qspi_defconfig   |   1 +
>  configs/ls1021atwr_nor_SECURE_BOOT_defconfig   |   1 +
>  configs/ls1021atwr_nor_defconfig   |   1 +
>  configs/ls1021atwr_nor_lpuart_defconfig|   1 +
>  configs/ls1021atwr_qspi_defconfig  |   1 +
>  .../ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig|   1 +
>  configs/ls1021atwr_sdcard_ifc_defconfig|   1 +
>  configs/ls1021atwr_sdcard_qspi_defconfig   |   1 +
>  drivers/video/Kconfig  |  15 +++
>  drivers/video/Makefile |   2 +-
>  drivers/video/fsl_dcu_fb.c | 124 
> ++---
>  include/configs/colibri_vf.h   |  18 ++-
>  include/configs/ls1021aqds.h   |   4 +-
>  include/configs/ls1021atwr.h   |   4 +-
>  include/fsl_dcu_fb.h   |   1 +
>  scripts/config_whitelist.txt   |   1 -
>  37 files changed, 318 insertions(+), 45 deletions(-)
>  create mode 100644 board/toradex/colibri_vf/dcu.c
> 
> -- 
> 2.11.1
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Build failure with u-boot master branch

[maitysanchayan]

Hello,

Any suggestions on the issue?

Thanks & Regards,
Sanchayan.

On 17-01-27 12:11:03, maitysancha...@gmail.com wrote:
> Hello,
> 
> I have been working on adding DCU support for Vybrid and during the process
> of rebasing to latest master for sending out patches, the build for u-boot 
> master branch fails with the following error
> 
>   HOSTCC  tools/gpimage-common.o
>   HOSTCC  tools/gpimage.o
>   HOSTCC  tools/dumpimage.o
>   HOSTCC  tools/mkimage.o
> LDFLAGS="" python ./lib/libfdt/setup.py \
>   "-Wall -Wstrict-prototypes -O2 -fomit-frame-pointer-include 
> ./include/libfdt_env.h -idirafterinclude -idirafter./arch/arm/include 
> -I./lib/libfdt 
> -I./tools -DCONFIG_SYS_TEXT_BASE=0x3f408000 -DUSE_HOSTCC 
> -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE " lib/libfdt/fdt.c lib/libfdt/fdt_ro.c 
> lib/libfdt/fdt_rw.c 
> lib/libfdt/fdt_strerror.c lib/libfdt/fdt_wip.c lib/libfdt/fdt_region.c 
> lib/libfdt/fdt_sw.c tools/libfdt_wrap.c
>   HOSTCC  tools/proftool
> mv _libfdt.so tools/_libfdt.so
> mv: cannot stat '_libfdt.so': No such file or directory
> make[1]: *** [tools/Makefile:121: tools/_libfdt.so] Error 1
> make[1]: *** Waiting for unfinished jobs
> make: *** [Makefile:1217: tools] Error 2
> 
> config file is colibri_vf_defconfig.
> 
> The earlier commit which worked for me was
> 
> commit 035ebf85b09cf11c820ae9eec414097420741abd
> Merge: cc422dae21 68e7999ba9
> Author: Tom Rini 
> Date:   Sun Jan 15 13:33:30 2017 -0500
> 
> Merge branch 'master' of git://git.denx.de/u-boot-spi
> 
> Is this is a known issue with a fix?
> 
> Thanks & Regards,
> Sanchayan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Build failure with u-boot master branch

[maitysanchayan]

Hello,

I have been working on adding DCU support for Vybrid and during the process
of rebasing to latest master for sending out patches, the build for u-boot 
master branch fails with the following error

  HOSTCC  tools/gpimage-common.o
  HOSTCC  tools/gpimage.o
  HOSTCC  tools/dumpimage.o
  HOSTCC  tools/mkimage.o
LDFLAGS="" python ./lib/libfdt/setup.py \
"-Wall -Wstrict-prototypes -O2 -fomit-frame-pointer-include 
./include/libfdt_env.h -idirafterinclude -idirafter./arch/arm/include 
-I./lib/libfdt 
-I./tools -DCONFIG_SYS_TEXT_BASE=0x3f408000 -DUSE_HOSTCC 
-D__KERNEL_STRICT_NAMES -D_GNU_SOURCE " lib/libfdt/fdt.c lib/libfdt/fdt_ro.c 
lib/libfdt/fdt_rw.c 
lib/libfdt/fdt_strerror.c lib/libfdt/fdt_wip.c lib/libfdt/fdt_region.c 
lib/libfdt/fdt_sw.c tools/libfdt_wrap.c
  HOSTCC  tools/proftool
mv _libfdt.so tools/_libfdt.so
mv: cannot stat '_libfdt.so': No such file or directory
make[1]: *** [tools/Makefile:121: tools/_libfdt.so] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:1217: tools] Error 2

config file is colibri_vf_defconfig.

The earlier commit which worked for me was

commit 035ebf85b09cf11c820ae9eec414097420741abd
Merge: cc422dae21 68e7999ba9
Author: Tom Rini 
Date:   Sun Jan 15 13:33:30 2017 -0500

Merge branch 'master' of git://git.denx.de/u-boot-spi

Is this is a known issue with a fix?

Thanks & Regards,
Sanchayan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/4] Migrate Vybrid USB driver to driver model

[maitysanchayan]

On 16-08-23 15:17:12, Marek Vasut wrote:
> On 08/09/2016 08:14 PM, Sanchayan Maity wrote:
> > Hello,
> > 
> > This is the second version of the patchset for migrating Vybrid
> > USB driver to driver model.
> > 
> > Compare to the first version, this version takes care of dr_mode
> > property and correctly handles OTG as well when gpio is specified
> > for use as ID detection pin. This is an essential requirement for
> > OTG as Vybrid USB controller is not a true OTG though it can be
> > configured as either host or device. The ID pin which is unique
> > for OTG operation is not present on Vybrid.
> > 
> > The problem with client that I was observing was related to sequence
> > numbers. While trying to implement the OTG functionality I observed
> > that if during probe of USB0 if it returns ENODEV, the probe of USB1
> > provides a sequence number of 0 while we expect 1. The code relies
> > on sequence numbers for initialising the appropriate peripherals.
> > I use the bind operation to force a sequence number. This also seems
> > to solve the problems I was having with USB client and mentioned
> > in the previous version of the patchset.
> > 
> > Host and client functionality are both functional with this patch.
> > Patch series is based on top of latest u-boot master at the moment
> > of this writing. Tested on Toradex Colibri Vybrid VF61 module.
> > 
> > Thanks to Lukasz and Stefan for their comments.
> > 
> > V1 Patches:
> > [1].
> > https://patchwork.ozlabs.org/patch/655370/
> > [2].
> > https://patchwork.ozlabs.org/patch/655371/
> > [3].
> > https://patchwork.ozlabs.org/patch/655372/
> > [4].
> > https://patchwork.ozlabs.org/patch/655373/
> > 
> > Sanchayan Maity (4):
> >   usb: host: ehci-vf: Migrate Vybrid USB to driver model
> >   ARM: dts: vf: Add device tree node for USB on Vybrid
> >   ARM: dts: vf-colibri: Enable USB device tree node for Colibri Vybrid
> >   configs: colibri_vf_defconfig: Enable USB driver model for Colibri Vybrid
> > 
> >  arch/arm/dts/vf-colibri.dtsi |  11 +++
> >  arch/arm/dts/vf.dtsi |  14 +++
> >  configs/colibri_vf_defconfig |   1 +
> >  drivers/usb/host/ehci-vf.c   | 208 
> > +--
> >  4 files changed, 227 insertions(+), 7 deletions(-)
> > 
> 
> Looks OK to me, Simon, since this is DM, can you review it ?
> 

Hello Simon,

Do you think the patchset is ok?

Thanks.

Regards,
Sanchayan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/4] Migrate Vybrid USB driver to driver model

[maitysanchayan]

Hello,

Ping?

Regards,
Sanchayan.

On 16-08-09 23:44:58, Sanchayan Maity wrote:
> Hello,
> 
> This is the second version of the patchset for migrating Vybrid
> USB driver to driver model.
> 
> Compare to the first version, this version takes care of dr_mode
> property and correctly handles OTG as well when gpio is specified
> for use as ID detection pin. This is an essential requirement for
> OTG as Vybrid USB controller is not a true OTG though it can be
> configured as either host or device. The ID pin which is unique
> for OTG operation is not present on Vybrid.
> 
> The problem with client that I was observing was related to sequence
> numbers. While trying to implement the OTG functionality I observed
> that if during probe of USB0 if it returns ENODEV, the probe of USB1
> provides a sequence number of 0 while we expect 1. The code relies
> on sequence numbers for initialising the appropriate peripherals.
> I use the bind operation to force a sequence number. This also seems
> to solve the problems I was having with USB client and mentioned
> in the previous version of the patchset.
> 
> Host and client functionality are both functional with this patch.
> Patch series is based on top of latest u-boot master at the moment
> of this writing. Tested on Toradex Colibri Vybrid VF61 module.
> 
> Thanks to Lukasz and Stefan for their comments.
> 
> V1 Patches:
> [1].
> https://patchwork.ozlabs.org/patch/655370/
> [2].
> https://patchwork.ozlabs.org/patch/655371/
> [3].
> https://patchwork.ozlabs.org/patch/655372/
> [4].
> https://patchwork.ozlabs.org/patch/655373/
> 
> Sanchayan Maity (4):
>   usb: host: ehci-vf: Migrate Vybrid USB to driver model
>   ARM: dts: vf: Add device tree node for USB on Vybrid
>   ARM: dts: vf-colibri: Enable USB device tree node for Colibri Vybrid
>   configs: colibri_vf_defconfig: Enable USB driver model for Colibri Vybrid
> 
>  arch/arm/dts/vf-colibri.dtsi |  11 +++
>  arch/arm/dts/vf.dtsi |  14 +++
>  configs/colibri_vf_defconfig |   1 +
>  drivers/usb/host/ehci-vf.c   | 208 
> +--
>  4 files changed, 227 insertions(+), 7 deletions(-)
> 
> -- 
> 2.9.2
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v1 1/4] usb: host: ehci-vf: Migrate Vybrid USB to driver model

[maitysanchayan]

Hello Lukasz,

On 16-08-09 15:20:58, Lukasz Majewski wrote:
> Hi maitysancha...@gmail.com,
> 
> > Hello,
> > 
> > Adding Lukasz's second mail ID to cc
> > 
> > On 16-08-08 11:45:35, maitysancha...@gmail.com wrote:
> > > Hello,
> > > 
> > > On 16-08-03 17:13:11, Marek Vasut wrote:
> > > > On 08/03/2016 01:58 PM, Sanchayan Maity wrote:
> > > > > Add driver model support for Vybrid USB driver.
> > > > > 
> > > > > Signed-off-by: Sanchayan Maity 
> > > > 
> > > > CCing Lukasz.
> > > > 
> > > > > ---
> > > > > Hello,
> > > > > 
> > > > > I am trying to migrate the Vybrid USB driver to driver model.
> > > > > Patches are based on top of uboot master branch. With this
> > > > > implementation, host works perfectly fine on both USB ports
> > > > > but I have problems using it in client mode.
> > > > > 
> > > > > I tried DFU to test client mode and I get the following
> > > > > 
> > > > > Colibri VFxx # version
> > > > > 
> > > > > U-Boot 2016.09-rc1-00235-g4e8c122 (Aug 03 2016 - 17:07:48 +0530)
> > > > > arm-linux-gnueabihf-gcc (Linaro GCC 5.2-2015.11-2) 5.2.1
> > > > > 20151005 GNU ld (GNU Binutils) 2.25.0 Linaro 2015_10
> > > > > Colibri VFxx # dfu 0 nand 4
> > > > > using id 'nand0,0'
> > > > > using id 'nand0,1'
> > > > > using id 'nand0,3'
> > > > > g_dnl_register: failed!, error: -19
> > > > > data abort
> > > > > pc : [<8ff80f18>]  lr : [<8ff612a9>]
> > > > > reloc pc : [<3f431f18>]lr : [<3f4122a9>]
> > > > > sp : 8fd15000  ip :  fp : 2710
> > > > > r10: 8ffb50cc  r9 : 8fd16ee8 r8 : 8ffbc574
> > > > > r7 :   r6 :  r5 :   r4 : 
> > > > > r3 : f4b9  r2 : 8000 r1 : 0001  r0 : 
> > > > > Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
> > > > > Resetting CPU ...
> > > > > 
> > > > > resetting ...
> 
> Patch for fixing this has been already posted by you. Thanks :-)

Happy to contribute :)

> 
> > > 
> > > FWIW here is output with DEBUG enabled in uclass.c
> > > 
> > > when testing with DFU:
> > > 
> > > uclass_find_device_by_seq: 1 0
> > >- -1 -1
> > >- -1 -1
> > >- not found
> > > g_dnl_register: failed!, error: -19
> > > data abort
> > > pc : [<8ff80fb0>]  lr : [<8ff612a9>]
> > > reloc pc : [<3f431fb0>]lr : [<3f4122a9>]
> > > sp : 8fd15000  ip :  fp : 2710
> > > r10: 8ffb5274  r9 : 8fd16ee8 r8 : 8ffbc714
> > > r7 :   r6 :  r5 :   r4 : 
> > > r3 : f4b9  r2 : 8000 r1 : 0001  r0 : 
> > > Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
> > > Resetting CPU ...
> > > 
> > > resetting ...
> > > 
> > > When testing host mode with usb start
> > > 
> > > Colibri VFxx # usb start
> > > starting USB...
> > > USB0:   uclass_find_device_by_seq: 0 -1
> > > uclass_find_device_by_seq: 0 0
> > >- -1 -1
> > >- -1 -1
> > >- not found
> > > USB EHCI 1.00
> > > USB1:   uclass_find_device_by_seq: 0 -1
> > > uclass_find_device_by_seq: 0 0
> > >- -1 0
> > >- found
> > > uclass_find_device_by_seq: 0 1
> > >- -1 0
> > >- -1 1
> > >- found
> > > uclass_find_device_by_seq: 0 2
> > >- -1 0
> > >- -1 1
> > >- -1 -1
> > >- not found
> > > uclass_find_device_by_seq: 0 -1
> > > uclass_find_device_by_seq: 0 0
> > >- -1 0
> > >- found
> > > uclass_find_device_by_seq: 0 1
> > >- -1 0
> > >- -1 -1
> > >- not found
> > > USB EHCI 1.00
> > > scanning bus 0 for devices... uclass_find_device_by_seq: 0 -1
> > > uclass_find_device_by_seq: 0 0
> > >- -1 -1
> > >- not found
> > > uclass_find_device_by_seq: 0 -1
> > > uclass_find_device_by_seq: 0 0
> > >- -1 -1
> > >- not found
> > > 2 USB Device(s) found
> > > scanning bus 1 for devices... uclass_find_device_by_seq: 0 -1
> > > uclass_find_device_by_seq: 0 0
> > >- -1 0
> > >- found
> > > uclass_find_device_by_seq: 0 1
> > >- -1 0
> > >- -1 -1
> > >- not found
> > > uclass_find_device_by_seq: 0 -1
> > > uclass_find_device_by_seq: 0 0
> > >- -1 0
> > >- found
> > > uclass_find_device_by_seq: 0 1
> > >- -1 0
> > >- -1 1
> > >- found
> > > uclass_find_device_by_seq: 0 2
> > >- -1 0
> > >- -1 1
> > >- -1 -1
> > >- not found
> > > 2 USB Device(s) found
> > > 
> > > Regards,
> > > Sanchayan.
> > > 
> > > > > 
> > > > > It seems to return ENODEV from usb_setup_ehci_gadget after
> > > > > calling uclass_find_device_by_seq. I am not sure what I am
> > > > > missing in the current implementation. Can someone point me in
> > > > > the correct direction? Since host works on both ports I would
> > > > > assume the device tree nodes are correct.
> 
> Please do not mix host and device controllers. Those are two disjoint
> drivers.

True. The idea is to have OTG functionality or at least client
functionality like DFU or UMS working when dr_mode is specified
as otg or peripheral from device tree.

> 
> What I can see, is that usb_gadget_register_driver() calls
> 

Re: [U-Boot] [PATCH v1 1/4] usb: host: ehci-vf: Migrate Vybrid USB to driver model

[maitysanchayan]

Hello Lukasz,

On 16-08-09 15:25:50, Lukasz Majewski wrote:
> Hi maitysancha...@gmail.com,
> 
> > Hello,
> > 
> > On 16-08-08 18:56:21, maitysancha...@gmail.com wrote:
> > > Hello,
> > > 
> > > Adding Lukasz's second mail ID to cc
> > > 
> > > On 16-08-08 11:45:35, maitysancha...@gmail.com wrote:
> > > > Hello,
> > > > 
> > > > On 16-08-03 17:13:11, Marek Vasut wrote:
> > > > > On 08/03/2016 01:58 PM, Sanchayan Maity wrote:
> > > > > > Add driver model support for Vybrid USB driver.
> > > > > > 
> > > > > > Signed-off-by: Sanchayan Maity 
> > > > > 
> > > > > CCing Lukasz.
> > > > > 
> > > > > > ---
> > > > > > Hello,
> > > > > > 
> > > > > > I am trying to migrate the Vybrid USB driver to driver model.
> > > > > > Patches are based on top of uboot master branch. With this
> > > > > > implementation, host works perfectly fine on both USB ports
> > > > > > but I have problems using it in client mode.
> > > > > > 
> > > > > > I tried DFU to test client mode and I get the following
> > > > > > 
> > > > > > Colibri VFxx # version
> > > > > > 
> > > > > > U-Boot 2016.09-rc1-00235-g4e8c122 (Aug 03 2016 - 17:07:48
> > > > > > +0530) arm-linux-gnueabihf-gcc (Linaro GCC 5.2-2015.11-2)
> > > > > > 5.2.1 20151005 GNU ld (GNU Binutils) 2.25.0 Linaro 2015_10
> > > > > > Colibri VFxx # dfu 0 nand 4
> > > > > > using id 'nand0,0'
> > > > > > using id 'nand0,1'
> > > > > > using id 'nand0,3'
> > > > > > g_dnl_register: failed!, error: -19
> > > > > > data abort
> > > > > > pc : [<8ff80f18>]  lr : [<8ff612a9>]
> > > > > > reloc pc : [<3f431f18>]lr : [<3f4122a9>]
> > > > > > sp : 8fd15000  ip :  fp : 2710
> > > > > > r10: 8ffb50cc  r9 : 8fd16ee8 r8 : 8ffbc574
> > > > > > r7 :   r6 :  r5 :   r4 : 
> > > > > > r3 : f4b9  r2 : 8000 r1 : 0001  r0 : 
> > > > > > Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
> > > > > > Resetting CPU ...
> > > > > > 
> > > > > > resetting ...
> > > > 
> > > > FWIW here is output with DEBUG enabled in uclass.c
> > > > 
> > > > when testing with DFU:
> > > > 
> > > > uclass_find_device_by_seq: 1 0
> > > >- -1 -1
> > > >- -1 -1
> > > >- not found
> > > > g_dnl_register: failed!, error: -19
> > > > data abort
> > > > pc : [<8ff80fb0>]  lr : [<8ff612a9>]
> > > > reloc pc : [<3f431fb0>]lr : [<3f4122a9>]
> > > > sp : 8fd15000  ip :  fp : 2710
> > > > r10: 8ffb5274  r9 : 8fd16ee8 r8 : 8ffbc714
> > > > r7 :   r6 :  r5 :   r4 : 
> > > > r3 : f4b9  r2 : 8000 r1 : 0001  r0 : 
> > > > Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
> > > > Resetting CPU ...
> > > > 
> > > > resetting ...
> > > > 
> > > > When testing host mode with usb start
> > > > 
> > > > Colibri VFxx # usb start
> > > > starting USB...
> > > > USB0:   uclass_find_device_by_seq: 0 -1
> > > > uclass_find_device_by_seq: 0 0
> > > >- -1 -1
> > > >- -1 -1
> > > >- not found
> > > > USB EHCI 1.00
> > > > USB1:   uclass_find_device_by_seq: 0 -1
> > > > uclass_find_device_by_seq: 0 0
> > > >- -1 0
> > > >- found
> > > > uclass_find_device_by_seq: 0 1
> > > >- -1 0
> > > >- -1 1
> > > >- found
> > > > uclass_find_device_by_seq: 0 2
> > > >- -1 0
> > > >- -1 1
> > > >- -1 -1
> > > >- not found
> > > > uclass_find_device_by_seq: 0 -1
> > > > uclass_find_device_by_seq: 0 0
> > > >- -1 0
> > > >- found
> > > > uclass_find_device_by_seq: 0 1
> > > >- -1 0
> > > >- -1 -1
> > > >- not found
> > > > USB EHCI 1.00
> > > > scanning bus 0 for devices... uclass_find_device_by_seq: 0 -1
> > > > uclass_find_device_by_seq: 0 0
> > > >- -1 -1
> > > >- not found
> > > > uclass_find_device_by_seq: 0 -1
> > > > uclass_find_device_by_seq: 0 0
> > > >- -1 -1
> > > >- not found
> > > > 2 USB Device(s) found
> > > > scanning bus 1 for devices... uclass_find_device_by_seq: 0 -1
> > > > uclass_find_device_by_seq: 0 0
> > > >- -1 0
> > > >- found
> > > > uclass_find_device_by_seq: 0 1
> > > >- -1 0
> > > >- -1 -1
> > > >- not found
> > > > uclass_find_device_by_seq: 0 -1
> > > > uclass_find_device_by_seq: 0 0
> > > >- -1 0
> > > >- found
> > > > uclass_find_device_by_seq: 0 1
> > > >- -1 0
> > > >- -1 1
> > > >- found
> > > > uclass_find_device_by_seq: 0 2
> > > >- -1 0
> > > >- -1 1
> > > >- -1 -1
> > > >- not found
> > > > 2 USB Device(s) found
> > > > 
> > > > Regards,
> > > > Sanchayan.
> > > > 
> > > > > > 
> > > > > > It seems to return ENODEV from usb_setup_ehci_gadget after
> > > > > > calling uclass_find_device_by_seq. I am not sure what I am
> > > > > > missing in the current implementation. Can someone point me
> > > > > > in the correct direction? Since host works on both ports I
> > > > > > would assume the device tree nodes are correct.
> > > > > > 
> > > > > > Tried to look in documentation and 

Re: [U-Boot] [PATCH v1 1/4] usb: host: ehci-vf: Migrate Vybrid USB to driver model

[maitysanchayan]

Hello,

On 16-08-08 18:56:21, maitysancha...@gmail.com wrote:
> Hello,
> 
> Adding Lukasz's second mail ID to cc
> 
> On 16-08-08 11:45:35, maitysancha...@gmail.com wrote:
> > Hello,
> > 
> > On 16-08-03 17:13:11, Marek Vasut wrote:
> > > On 08/03/2016 01:58 PM, Sanchayan Maity wrote:
> > > > Add driver model support for Vybrid USB driver.
> > > > 
> > > > Signed-off-by: Sanchayan Maity 
> > > 
> > > CCing Lukasz.
> > > 
> > > > ---
> > > > Hello,
> > > > 
> > > > I am trying to migrate the Vybrid USB driver to driver model.
> > > > Patches are based on top of uboot master branch. With this
> > > > implementation, host works perfectly fine on both USB ports
> > > > but I have problems using it in client mode.
> > > > 
> > > > I tried DFU to test client mode and I get the following
> > > > 
> > > > Colibri VFxx # version
> > > > 
> > > > U-Boot 2016.09-rc1-00235-g4e8c122 (Aug 03 2016 - 17:07:48 +0530)
> > > > arm-linux-gnueabihf-gcc (Linaro GCC 5.2-2015.11-2) 5.2.1 20151005
> > > > GNU ld (GNU Binutils) 2.25.0 Linaro 2015_10
> > > > Colibri VFxx # dfu 0 nand 4
> > > > using id 'nand0,0'
> > > > using id 'nand0,1'
> > > > using id 'nand0,3'
> > > > g_dnl_register: failed!, error: -19
> > > > data abort
> > > > pc : [<8ff80f18>]  lr : [<8ff612a9>]
> > > > reloc pc : [<3f431f18>]lr : [<3f4122a9>]
> > > > sp : 8fd15000  ip :  fp : 2710
> > > > r10: 8ffb50cc  r9 : 8fd16ee8 r8 : 8ffbc574
> > > > r7 :   r6 :  r5 :   r4 : 
> > > > r3 : f4b9  r2 : 8000 r1 : 0001  r0 : 
> > > > Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
> > > > Resetting CPU ...
> > > > 
> > > > resetting ...
> > 
> > FWIW here is output with DEBUG enabled in uclass.c
> > 
> > when testing with DFU:
> > 
> > uclass_find_device_by_seq: 1 0
> >- -1 -1
> >- -1 -1
> >- not found
> > g_dnl_register: failed!, error: -19
> > data abort
> > pc : [<8ff80fb0>]  lr : [<8ff612a9>]
> > reloc pc : [<3f431fb0>]lr : [<3f4122a9>]
> > sp : 8fd15000  ip :  fp : 2710
> > r10: 8ffb5274  r9 : 8fd16ee8 r8 : 8ffbc714
> > r7 :   r6 :  r5 :   r4 : 
> > r3 : f4b9  r2 : 8000 r1 : 0001  r0 : 
> > Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
> > Resetting CPU ...
> > 
> > resetting ...
> > 
> > When testing host mode with usb start
> > 
> > Colibri VFxx # usb start
> > starting USB...
> > USB0:   uclass_find_device_by_seq: 0 -1
> > uclass_find_device_by_seq: 0 0
> >- -1 -1
> >- -1 -1
> >- not found
> > USB EHCI 1.00
> > USB1:   uclass_find_device_by_seq: 0 -1
> > uclass_find_device_by_seq: 0 0
> >- -1 0
> >- found
> > uclass_find_device_by_seq: 0 1
> >- -1 0
> >- -1 1
> >- found
> > uclass_find_device_by_seq: 0 2
> >- -1 0
> >- -1 1
> >- -1 -1
> >- not found
> > uclass_find_device_by_seq: 0 -1
> > uclass_find_device_by_seq: 0 0
> >- -1 0
> >- found
> > uclass_find_device_by_seq: 0 1
> >- -1 0
> >- -1 -1
> >- not found
> > USB EHCI 1.00
> > scanning bus 0 for devices... uclass_find_device_by_seq: 0 -1
> > uclass_find_device_by_seq: 0 0
> >- -1 -1
> >- not found
> > uclass_find_device_by_seq: 0 -1
> > uclass_find_device_by_seq: 0 0
> >- -1 -1
> >- not found
> > 2 USB Device(s) found
> > scanning bus 1 for devices... uclass_find_device_by_seq: 0 -1
> > uclass_find_device_by_seq: 0 0
> >- -1 0
> >- found
> > uclass_find_device_by_seq: 0 1
> >- -1 0
> >- -1 -1
> >- not found
> > uclass_find_device_by_seq: 0 -1
> > uclass_find_device_by_seq: 0 0
> >- -1 0
> >- found
> > uclass_find_device_by_seq: 0 1
> >- -1 0
> >- -1 1
> >- found
> > uclass_find_device_by_seq: 0 2
> >- -1 0
> >- -1 1
> >- -1 -1
> >- not found
> > 2 USB Device(s) found
> > 
> > Regards,
> > Sanchayan.
> > 
> > > > 
> > > > It seems to return ENODEV from usb_setup_ehci_gadget after calling
> > > > uclass_find_device_by_seq. I am not sure what I am missing in the
> > > > current implementation. Can someone point me in the correct direction?
> > > > Since host works on both ports I would assume the device tree nodes
> > > > are correct.
> > > > 
> > > > Tried to look in documentation and usb-info.txt mentions that gadget
> > > > framework does not use driver model. Does this imply I cannot use
> > > > any usb gadget functionality if I am using USB DM? However the function
> > > > usb_gadget_register_driver in ci_udc.c does have a CONFIG_DM_USB and
> > > > calls into usb_setup_ehci_gadget which is in usb-uclass.c.
> 
> @Lukasz
> Can you comment?

diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c
index be114fc..1bcd73f 100644
--- a/drivers/usb/host/usb-uclass.c
+++ b/drivers/usb/host/usb-uclass.c
@@ -355,7 +355,7 @@ int usb_setup_ehci_gadget(struct ehci_ctrl **ctlrp)
int ret;
 
/* Find the old device and remove it */
-   

Re: [U-Boot] [PATCH v1 1/4] usb: host: ehci-vf: Migrate Vybrid USB to driver model

[maitysanchayan]

Hello,

Adding Lukasz's second mail ID to cc

On 16-08-08 11:45:35, maitysancha...@gmail.com wrote:
> Hello,
> 
> On 16-08-03 17:13:11, Marek Vasut wrote:
> > On 08/03/2016 01:58 PM, Sanchayan Maity wrote:
> > > Add driver model support for Vybrid USB driver.
> > > 
> > > Signed-off-by: Sanchayan Maity 
> > 
> > CCing Lukasz.
> > 
> > > ---
> > > Hello,
> > > 
> > > I am trying to migrate the Vybrid USB driver to driver model.
> > > Patches are based on top of uboot master branch. With this
> > > implementation, host works perfectly fine on both USB ports
> > > but I have problems using it in client mode.
> > > 
> > > I tried DFU to test client mode and I get the following
> > > 
> > > Colibri VFxx # version
> > > 
> > > U-Boot 2016.09-rc1-00235-g4e8c122 (Aug 03 2016 - 17:07:48 +0530)
> > > arm-linux-gnueabihf-gcc (Linaro GCC 5.2-2015.11-2) 5.2.1 20151005
> > > GNU ld (GNU Binutils) 2.25.0 Linaro 2015_10
> > > Colibri VFxx # dfu 0 nand 4
> > > using id 'nand0,0'
> > > using id 'nand0,1'
> > > using id 'nand0,3'
> > > g_dnl_register: failed!, error: -19
> > > data abort
> > > pc : [<8ff80f18>]  lr : [<8ff612a9>]
> > > reloc pc : [<3f431f18>]lr : [<3f4122a9>]
> > > sp : 8fd15000  ip :  fp : 2710
> > > r10: 8ffb50cc  r9 : 8fd16ee8 r8 : 8ffbc574
> > > r7 :   r6 :  r5 :   r4 : 
> > > r3 : f4b9  r2 : 8000 r1 : 0001  r0 : 
> > > Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
> > > Resetting CPU ...
> > > 
> > > resetting ...
> 
> FWIW here is output with DEBUG enabled in uclass.c
> 
> when testing with DFU:
> 
> uclass_find_device_by_seq: 1 0
>- -1 -1
>- -1 -1
>- not found
> g_dnl_register: failed!, error: -19
> data abort
> pc : [<8ff80fb0>]  lr : [<8ff612a9>]
> reloc pc : [<3f431fb0>]lr : [<3f4122a9>]
> sp : 8fd15000  ip :  fp : 2710
> r10: 8ffb5274  r9 : 8fd16ee8 r8 : 8ffbc714
> r7 :   r6 :  r5 :   r4 : 
> r3 : f4b9  r2 : 8000 r1 : 0001  r0 : 
> Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
> Resetting CPU ...
> 
> resetting ...
> 
> When testing host mode with usb start
> 
> Colibri VFxx # usb start
> starting USB...
> USB0:   uclass_find_device_by_seq: 0 -1
> uclass_find_device_by_seq: 0 0
>- -1 -1
>- -1 -1
>- not found
> USB EHCI 1.00
> USB1:   uclass_find_device_by_seq: 0 -1
> uclass_find_device_by_seq: 0 0
>- -1 0
>- found
> uclass_find_device_by_seq: 0 1
>- -1 0
>- -1 1
>- found
> uclass_find_device_by_seq: 0 2
>- -1 0
>- -1 1
>- -1 -1
>- not found
> uclass_find_device_by_seq: 0 -1
> uclass_find_device_by_seq: 0 0
>- -1 0
>- found
> uclass_find_device_by_seq: 0 1
>- -1 0
>- -1 -1
>- not found
> USB EHCI 1.00
> scanning bus 0 for devices... uclass_find_device_by_seq: 0 -1
> uclass_find_device_by_seq: 0 0
>- -1 -1
>- not found
> uclass_find_device_by_seq: 0 -1
> uclass_find_device_by_seq: 0 0
>- -1 -1
>- not found
> 2 USB Device(s) found
> scanning bus 1 for devices... uclass_find_device_by_seq: 0 -1
> uclass_find_device_by_seq: 0 0
>- -1 0
>- found
> uclass_find_device_by_seq: 0 1
>- -1 0
>- -1 -1
>- not found
> uclass_find_device_by_seq: 0 -1
> uclass_find_device_by_seq: 0 0
>- -1 0
>- found
> uclass_find_device_by_seq: 0 1
>- -1 0
>- -1 1
>- found
> uclass_find_device_by_seq: 0 2
>- -1 0
>- -1 1
>- -1 -1
>- not found
> 2 USB Device(s) found
> 
> Regards,
> Sanchayan.
> 
> > > 
> > > It seems to return ENODEV from usb_setup_ehci_gadget after calling
> > > uclass_find_device_by_seq. I am not sure what I am missing in the
> > > current implementation. Can someone point me in the correct direction?
> > > Since host works on both ports I would assume the device tree nodes
> > > are correct.
> > > 
> > > Tried to look in documentation and usb-info.txt mentions that gadget
> > > framework does not use driver model. Does this imply I cannot use
> > > any usb gadget functionality if I am using USB DM? However the function
> > > usb_gadget_register_driver in ci_udc.c does have a CONFIG_DM_USB and
> > > calls into usb_setup_ehci_gadget which is in usb-uclass.c.

@Lukasz
Can you comment?

Regards,
Sanchayan.

> > > 
> > > Regards,
> > > Sanchayan.
> > > ---
> > >  drivers/usb/host/ehci-vf.c | 123 
> > > ++---
> > >  1 file changed, 117 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/usb/host/ehci-vf.c b/drivers/usb/host/ehci-vf.c
> > > index 61789dd..8c5c593 100644
> > > --- a/drivers/usb/host/ehci-vf.c
> > > +++ b/drivers/usb/host/ehci-vf.c
> > > @@ -8,6 +8,7 @@
> > >   */
> > >  
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -131,6 +132,24 @@ int __weak board_ehci_hcd_init(int port)
> > >   return 0;
> > >  }
> > >  
> > > +int ehci_vf_common_init(struct 

Re: [U-Boot] [PATCH v1 1/4] usb: host: ehci-vf: Migrate Vybrid USB to driver model

[maitysanchayan]

Hello Stefan,

On 16-08-08 00:25:16, Stefan Agner wrote:
> On 2016-08-07 23:15, maitysancha...@gmail.com wrote:
> > Hello,
> > 
> > On 16-08-03 17:13:11, Marek Vasut wrote:
> >> On 08/03/2016 01:58 PM, Sanchayan Maity wrote:
> >> > Add driver model support for Vybrid USB driver.
> >> >
> >> > Signed-off-by: Sanchayan Maity 
> >>
> >> CCing Lukasz.
> >>
> >> > ---
> >> > Hello,
> >> >
> >> > I am trying to migrate the Vybrid USB driver to driver model.
> >> > Patches are based on top of uboot master branch. With this
> >> > implementation, host works perfectly fine on both USB ports
> >> > but I have problems using it in client mode.
> >> >
> >> > I tried DFU to test client mode and I get the following
> >> >
> >> > Colibri VFxx # version
> >> >
> >> > U-Boot 2016.09-rc1-00235-g4e8c122 (Aug 03 2016 - 17:07:48 +0530)
> >> > arm-linux-gnueabihf-gcc (Linaro GCC 5.2-2015.11-2) 5.2.1 20151005
> >> > GNU ld (GNU Binutils) 2.25.0 Linaro 2015_10
> >> > Colibri VFxx # dfu 0 nand 4
> >> > using id 'nand0,0'
> >> > using id 'nand0,1'
> >> > using id 'nand0,3'
> >> > g_dnl_register: failed!, error: -19
> >> > data abort
> >> > pc : [<8ff80f18>]  lr : [<8ff612a9>]
> >> > reloc pc : [<3f431f18>]lr : [<3f4122a9>]
> >> > sp : 8fd15000  ip :  fp : 2710
> >> > r10: 8ffb50cc  r9 : 8fd16ee8 r8 : 8ffbc574
> >> > r7 :   r6 :  r5 :   r4 : 
> >> > r3 : f4b9  r2 : 8000 r1 : 0001  r0 : 
> >> > Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
> >> > Resetting CPU ...
> >> >
> >> > resetting ...
> > 
> > FWIW here is output with DEBUG enabled in uclass.c
> > 
> > when testing with DFU:
> > 
> > uclass_find_device_by_seq: 1 0
> >- -1 -1
> >- -1 -1
> >- not found
> > g_dnl_register: failed!, error: -19
> 
> Hm, I guess this comes from usb_setup_ehci_gadget called through
> usb_gadget_register_driver. The call in there seems rather hardcoded:

Yes it comes from that function.

> 
> ret = uclass_find_device_by_seq(UCLASS_USB, 0, true, );
> (seq = 0, and find_req_seq=true, maybe find_req_seq=false helps? Maybe
> it is because we use the second USB DR controller for OTG?)

I have already tried using that value along with what I see during
use as USB host.

While eventually the second USB controller is to be used as OTG for
us, the point of failure is even before the device_probe call in
usb_setup_ehci_gadget. Also before the device probe call the plat->
init_type is set to USB_DEVICE and I have not yet added the type
check in usb_probe function akin to the non DM case in ehci_hcd_init
which takes care of OTG handling.

Something related to sequence numbers and uclass device. I tried
DM_UC_FLAG_SEQ_ALIAS but that seems to be specified for UCLASS USB
anyways.

Regards,
Sanchayan,

> 
> 
> > data abort
> > pc : [<8ff80fb0>]  lr : [<8ff612a9>]
> > reloc pc : [<3f431fb0>]lr : [<3f4122a9>]
> > sp : 8fd15000  ip :  fp : 2710
> > r10: 8ffb5274  r9 : 8fd16ee8 r8 : 8ffbc714
> > r7 :   r6 :  r5 :   r4 : 
> > r3 : f4b9  r2 : 8000 r1 : 0001  r0 : 
> > Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
> > Resetting CPU ...
> 
> I guess that comes from cmd/dfu.c not handling the error code of
> g_dnl_register...
> 
> --
> Stefan
> 
> > 
> > resetting ...
> > 
> > When testing host mode with usb start
> > 
> > Colibri VFxx # usb start
> > starting USB...
> > USB0:   uclass_find_device_by_seq: 0 -1
> > uclass_find_device_by_seq: 0 0
> >- -1 -1
> >- -1 -1
> >- not found
> > USB EHCI 1.00
> > USB1:   uclass_find_device_by_seq: 0 -1
> > uclass_find_device_by_seq: 0 0
> >- -1 0
> >- found
> > uclass_find_device_by_seq: 0 1
> >- -1 0
> >- -1 1
> >- found
> > uclass_find_device_by_seq: 0 2
> >- -1 0
> >- -1 1
> >- -1 -1
> >- not found
> > uclass_find_device_by_seq: 0 -1
> > uclass_find_device_by_seq: 0 0
> >- -1 0
> >- found
> > uclass_find_device_by_seq: 0 1
> >- -1 0
> >- -1 -1
> >- not found
> > USB EHCI 1.00
> > scanning bus 0 for devices... uclass_find_device_by_seq: 0 -1
> > uclass_find_device_by_seq: 0 0
> >- -1 -1
> >- not found
> > uclass_find_device_by_seq: 0 -1
> > uclass_find_device_by_seq: 0 0
> >- -1 -1
> >- not found
> > 2 USB Device(s) found
> > scanning bus 1 for devices... uclass_find_device_by_seq: 0 -1
> > uclass_find_device_by_seq: 0 0
> >- -1 0
> >- found
> > uclass_find_device_by_seq: 0 1
> >- -1 0
> >- -1 -1
> >- not found
> > uclass_find_device_by_seq: 0 -1
> > uclass_find_device_by_seq: 0 0
> >- -1 0
> >- found
> > uclass_find_device_by_seq: 0 1
> >- -1 0
> >- -1 1
> >- found
> > uclass_find_device_by_seq: 0 2
> >- -1 0
> >- -1 1
> >- -1 -1
> >- not found
> > 2 USB Device(s) found
> > 
> > Regards,
> > Sanchayan.
> > 
> >> >
> >> > It seems to return ENODEV from usb_setup_ehci_gadget after 

Re: [U-Boot] [PATCH v1 1/4] usb: host: ehci-vf: Migrate Vybrid USB to driver model

[maitysanchayan]

Hello,

On 16-08-03 17:13:11, Marek Vasut wrote:
> On 08/03/2016 01:58 PM, Sanchayan Maity wrote:
> > Add driver model support for Vybrid USB driver.
> > 
> > Signed-off-by: Sanchayan Maity 
> 
> CCing Lukasz.
> 
> > ---
> > Hello,
> > 
> > I am trying to migrate the Vybrid USB driver to driver model.
> > Patches are based on top of uboot master branch. With this
> > implementation, host works perfectly fine on both USB ports
> > but I have problems using it in client mode.
> > 
> > I tried DFU to test client mode and I get the following
> > 
> > Colibri VFxx # version
> > 
> > U-Boot 2016.09-rc1-00235-g4e8c122 (Aug 03 2016 - 17:07:48 +0530)
> > arm-linux-gnueabihf-gcc (Linaro GCC 5.2-2015.11-2) 5.2.1 20151005
> > GNU ld (GNU Binutils) 2.25.0 Linaro 2015_10
> > Colibri VFxx # dfu 0 nand 4
> > using id 'nand0,0'
> > using id 'nand0,1'
> > using id 'nand0,3'
> > g_dnl_register: failed!, error: -19
> > data abort
> > pc : [<8ff80f18>]  lr : [<8ff612a9>]
> > reloc pc : [<3f431f18>]lr : [<3f4122a9>]
> > sp : 8fd15000  ip :  fp : 2710
> > r10: 8ffb50cc  r9 : 8fd16ee8 r8 : 8ffbc574
> > r7 :   r6 :  r5 :   r4 : 
> > r3 : f4b9  r2 : 8000 r1 : 0001  r0 : 
> > Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
> > Resetting CPU ...
> > 
> > resetting ...

FWIW here is output with DEBUG enabled in uclass.c

when testing with DFU:

uclass_find_device_by_seq: 1 0
   - -1 -1
   - -1 -1
   - not found
g_dnl_register: failed!, error: -19
data abort
pc : [<8ff80fb0>]  lr : [<8ff612a9>]
reloc pc : [<3f431fb0>]lr : [<3f4122a9>]
sp : 8fd15000  ip :  fp : 2710
r10: 8ffb5274  r9 : 8fd16ee8 r8 : 8ffbc714
r7 :   r6 :  r5 :   r4 : 
r3 : f4b9  r2 : 8000 r1 : 0001  r0 : 
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...

When testing host mode with usb start

Colibri VFxx # usb start
starting USB...
USB0:   uclass_find_device_by_seq: 0 -1
uclass_find_device_by_seq: 0 0
   - -1 -1
   - -1 -1
   - not found
USB EHCI 1.00
USB1:   uclass_find_device_by_seq: 0 -1
uclass_find_device_by_seq: 0 0
   - -1 0
   - found
uclass_find_device_by_seq: 0 1
   - -1 0
   - -1 1
   - found
uclass_find_device_by_seq: 0 2
   - -1 0
   - -1 1
   - -1 -1
   - not found
uclass_find_device_by_seq: 0 -1
uclass_find_device_by_seq: 0 0
   - -1 0
   - found
uclass_find_device_by_seq: 0 1
   - -1 0
   - -1 -1
   - not found
USB EHCI 1.00
scanning bus 0 for devices... uclass_find_device_by_seq: 0 -1
uclass_find_device_by_seq: 0 0
   - -1 -1
   - not found
uclass_find_device_by_seq: 0 -1
uclass_find_device_by_seq: 0 0
   - -1 -1
   - not found
2 USB Device(s) found
scanning bus 1 for devices... uclass_find_device_by_seq: 0 -1
uclass_find_device_by_seq: 0 0
   - -1 0
   - found
uclass_find_device_by_seq: 0 1
   - -1 0
   - -1 -1
   - not found
uclass_find_device_by_seq: 0 -1
uclass_find_device_by_seq: 0 0
   - -1 0
   - found
uclass_find_device_by_seq: 0 1
   - -1 0
   - -1 1
   - found
uclass_find_device_by_seq: 0 2
   - -1 0
   - -1 1
   - -1 -1
   - not found
2 USB Device(s) found

Regards,
Sanchayan.

> > 
> > It seems to return ENODEV from usb_setup_ehci_gadget after calling
> > uclass_find_device_by_seq. I am not sure what I am missing in the
> > current implementation. Can someone point me in the correct direction?
> > Since host works on both ports I would assume the device tree nodes
> > are correct.
> > 
> > Tried to look in documentation and usb-info.txt mentions that gadget
> > framework does not use driver model. Does this imply I cannot use
> > any usb gadget functionality if I am using USB DM? However the function
> > usb_gadget_register_driver in ci_udc.c does have a CONFIG_DM_USB and
> > calls into usb_setup_ehci_gadget which is in usb-uclass.c.
> > 
> > Regards,
> > Sanchayan.
> > ---
> >  drivers/usb/host/ehci-vf.c | 123 
> > ++---
> >  1 file changed, 117 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/usb/host/ehci-vf.c b/drivers/usb/host/ehci-vf.c
> > index 61789dd..8c5c593 100644
> > --- a/drivers/usb/host/ehci-vf.c
> > +++ b/drivers/usb/host/ehci-vf.c
> > @@ -8,6 +8,7 @@
> >   */
> >  
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -131,6 +132,24 @@ int __weak board_ehci_hcd_init(int port)
> > return 0;
> >  }
> >  
> > +int ehci_vf_common_init(struct usb_ehci *ehci, int index)
> > +{
> > +   int ret;
> > +
> > +   /* Do board specific initialisation */
> > +   ret = board_ehci_hcd_init(index);
> > +   if (ret)
> > +   return ret;
> > +
> > +   usb_power_config(index);
> > +   usb_oc_config(index);
> > +   usb_internal_phy_clock_gate(index);
> > +   usb_phy_enable(index, ehci);
> > +
> > +   return 0;
> > +}
> > +
> > +#ifndef CONFIG_DM_USB
> >  int ehci_hcd_init(int index, enum usb_init_type init,
> > 

Re: [U-Boot] [PATCH v5] colibri_vf: Add board_usb_phy_mode function

[maitysanchayan]

On 16-01-08 13:11:27, Marek Vasut wrote:
> On Friday, January 08, 2016 at 06:50:41 AM, maitysancha...@gmail.com wrote:
> > Hello,
> > 
> > On 16-01-07 22:12:29, Stefano Babic wrote:
> > > Hi,
> > > 
> > > On 07/01/2016 21:02, maitysancha...@gmail.com wrote:
> > > > Hello Stefano,
> > > > 
> > > > Ping?
> > > > 
> > > > I just checked the master branch and this has not been picked up yet.
> > > 
> > > Can you check ? I see:
> > > 
> > > commit 01a8cf91513981d05bf89840d768e9c060ee998b
> > > Author: Sanchayan Maity 
> > > Date:   Thu Nov 12 11:47:35 2015 +0530
> > > 
> > > colibri_vf: Add board_usb_phy_mode function
> > 
> > Yes, this seems to be present but the first and second patch in the series
> > which make changes to the ehci-vf driver are not present.
> 
> But this is only a single patch here , even the subject indicates so ... ?

Hmm I guess I get it. This patch I had send as a reply to the 3rd patch in a 
thread
of a 3 patch series

http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/238549

My bad. Sorry about the confusion. I will ping on the respective individual 1st 
and 2nd patch.

- Sanchayan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] usb: host: ehci-vf: Remove hardcoded USB host client configuration

[maitysanchayan]

Hello Stefano / Marek,

Can you pick this up? 

- Sanchayan.

On 15-10-26 18:28:49, Sanchayan Maity wrote:
> The current ehci-vf USB driver for Vybrid hardcodes the USB host
> and client functionality. Remove this.
> 
> Reported-by: Santhosh Kumar Janardhanam 
> Signed-off-by: Sanchayan Maity 
> ---
>  drivers/usb/host/ehci-vf.c | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/drivers/usb/host/ehci-vf.c b/drivers/usb/host/ehci-vf.c
> index 98e0fc6..351e0fb 100644
> --- a/drivers/usb/host/ehci-vf.c
> +++ b/drivers/usb/host/ehci-vf.c
> @@ -134,11 +134,6 @@ int ehci_hcd_init(int index, enum usb_init_type init,
>   if (index >= ARRAY_SIZE(nc_reg_bases))
>   return -EINVAL;
>  
> - if (init == USB_INIT_DEVICE && index == 1)
> - return -ENODEV;
> - if (init == USB_INIT_HOST && index == 0)
> - return -ENODEV;
> -
>   ehci = (struct usb_ehci *)nc_reg_bases[index];
>  
>   /* Do board specific initialisation */
> -- 
> 2.6.2
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] usb: host: ehci-vf: Implement board_usb_phy_mode weak function

[maitysanchayan]

Hello Stefano / Marek,

Can you pick this up?

- Sanchayan.

On 15-10-26 18:28:50, Sanchayan Maity wrote:
> Add board_usb_phy_mode weak function on similar lines to ehci-mx6.
> However since Vybrid USB does not have a true OTG, make this weak
> functon just return 0. The function is supposed to be implemented
> by the individual boards using a GPIO for providing the OTG pin
> functionality.
> 
> Signed-off-by: Sanchayan Maity 
> ---
> There seems to be a problem here. As per DFU's help note,
> the first argument to dfu is the USB controller.
> 
> So if dfu 1 nand 2 is run, I would expect the ehci_hcd_init
> function's first index argument to recieve 1. However this
> does not seem to be the case. Not sure if I am understanding
> something wrongly here. Is this expected?
> 
> Currently because of this even though I did like dfu 1 nand 2
> to bail out, it does not. I tried tracing the code from do_dfu
> but I have yet to get from where ehci_hcd_init is getting called
> in the call chain.
> 
> All seems to be well when using usb start.
> 
> ---
>  drivers/usb/host/ehci-vf.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/usb/host/ehci-vf.c b/drivers/usb/host/ehci-vf.c
> index 351e0fb..335e303 100644
> --- a/drivers/usb/host/ehci-vf.c
> +++ b/drivers/usb/host/ehci-vf.c
> @@ -121,6 +121,11 @@ static void usb_oc_config(int index)
>   setbits_le32(ctrl, UCTRL_OVER_CUR_DIS);
>  }
>  
> +int __weak board_usb_phy_mode(int port)
> +{
> + return 0;
> +}
> +
>  int __weak board_ehci_hcd_init(int port)
>  {
>   return 0;
> @@ -130,6 +135,7 @@ int ehci_hcd_init(int index, enum usb_init_type init,
>   struct ehci_hccr **hccr, struct ehci_hcor **hcor)
>  {
>   struct usb_ehci *ehci;
> + enum usb_init_type type;
>  
>   if (index >= ARRAY_SIZE(nc_reg_bases))
>   return -EINVAL;
> @@ -148,6 +154,10 @@ int ehci_hcd_init(int index, enum usb_init_type init,
>   *hcor = (struct ehci_hcor *)((uint32_t)*hccr +
>   HC_LENGTH(ehci_readl(&(*hccr)->cr_capbase)));
>  
> + type = board_usb_phy_mode(index);
> + if (type != init)
> + return -ENODEV;
> +
>   if (init == USB_INIT_DEVICE) {
>   setbits_le32(>usbmode, CM_DEVICE);
>   writel((PORT_PTS_UTMI | PORT_PTS_PTW), >portsc);
> -- 
> 2.6.2
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] usb: host: ehci-vf: Remove hardcoded USB host client configuration

[maitysanchayan]

Hello Marek,

On 16-01-08 13:26:32, Marek Vasut wrote:
> On Friday, January 08, 2016 at 01:20:23 PM, maitysancha...@gmail.com wrote:
> > Hello Stefano / Marek,
> > 
> > Can you pick this up?
> 
> I can, but only for next. Is that fine ?

Yes it's fine. Thank you.

- Sanchayan.

> > 
> > On 15-10-26 18:28:49, Sanchayan Maity wrote:
> > > The current ehci-vf USB driver for Vybrid hardcodes the USB host
> > > and client functionality. Remove this.
> > > 
> > > Reported-by: Santhosh Kumar Janardhanam 
> > > Signed-off-by: Sanchayan Maity 
> > > ---
> > > 
> > >  drivers/usb/host/ehci-vf.c | 5 -
> > >  1 file changed, 5 deletions(-)
> > > 
> > > diff --git a/drivers/usb/host/ehci-vf.c b/drivers/usb/host/ehci-vf.c
> > > index 98e0fc6..351e0fb 100644
> > > --- a/drivers/usb/host/ehci-vf.c
> > > +++ b/drivers/usb/host/ehci-vf.c
> > > @@ -134,11 +134,6 @@ int ehci_hcd_init(int index, enum usb_init_type
> > > init,
> > > 
> > >   if (index >= ARRAY_SIZE(nc_reg_bases))
> > >   
> > >   return -EINVAL;
> > > 
> > > - if (init == USB_INIT_DEVICE && index == 1)
> > > - return -ENODEV;
> > > - if (init == USB_INIT_HOST && index == 0)
> > > - return -ENODEV;
> > > -
> > > 
> > >   ehci = (struct usb_ehci *)nc_reg_bases[index];
> > >   
> > >   /* Do board specific initialisation */
> 
> Best regards,
> Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5] colibri_vf: Add board_usb_phy_mode function

[maitysanchayan]

Hello,

On 16-01-07 22:12:29, Stefano Babic wrote:
> Hi,
> 
> On 07/01/2016 21:02, maitysancha...@gmail.com wrote:
> > Hello Stefano,
> > 
> > Ping?
> > 
> > I just checked the master branch and this has not been picked up yet.
> > 
> 
> Can you check ? I see:
> 
> commit 01a8cf91513981d05bf89840d768e9c060ee998b
> Author: Sanchayan Maity 
> Date:   Thu Nov 12 11:47:35 2015 +0530
> 
> colibri_vf: Add board_usb_phy_mode function

Yes, this seems to be present but the first and second patch in the series
which make changes to the ehci-vf driver are not present.

- Sanchayan.

> 
> Regards,
> Stefano
> 
> > - Sanchayan.
> > 
> > On 15-11-24 11:37:59, Stefano Babic wrote:
> >> On 24/11/2015 11:23, maitysancha...@gmail.com wrote:
> >>> Hello,
> >>>
> >>> Ping?
> >>>
> >>> Any further feedback? Is the patchset good to get accepted?
> >>
> >> I'll pick it up
> >>
> >> Best regards,
> >> Stefano Babic
> >>
> >>>
> >>> Thanks.
> >>>
> >>> Regards,
> >>> Sanchayan.
> >>>
> >>> On 15-11-12 11:47:35, Sanchayan Maity wrote:
>  Add board_usb_phy_mode function for detecting whether a port is
>  being used as host or client using a GPIO. On Colibri Vybrid we
>  provide GPIO 102 for this very same purpose.
> 
>  Signed-off-by: Sanchayan Maity 
>  ---
>  Changes since v4:
>  No need to break after return.
> 
>  Changes since v3:
>  Return USB_INIT_DEVICE or USB_INIT_HOST after checking for
>  the GPIO state to account for the fact that the previous
>  logic breaks in case if the enum for USB mode were to ever
>  be changed.
> 
>  Add comments based on Stefan's feedback.
> 
>  Changes since v2:
> 
>  Instead of returning 0 from board_usb_phy_mode return it as
>  USB_INIT_HOST.
> 
>  Changes since v1:
> 
>  Move the GPIO request call to the board_init function as all
>  further calls to board_usb_phy_mode will actually result in the
>  gpio_request failing.
>  ---
>   board/toradex/colibri_vf/colibri_vf.c | 33 
>  -
>   1 file changed, 32 insertions(+), 1 deletion(-)
> 
>  diff --git a/board/toradex/colibri_vf/colibri_vf.c 
>  b/board/toradex/colibri_vf/colibri_vf.c
>  index a6d1c5b..c65ccb3 100644
>  --- a/board/toradex/colibri_vf/colibri_vf.c
>  +++ b/board/toradex/colibri_vf/colibri_vf.c
>  @@ -21,6 +21,7 @@
>   #include 
>   #include 
>   #include 
>  +#include 
>   
>   DECLARE_GLOBAL_DATA_PTR;
>   
>  @@ -34,6 +35,7 @@ DECLARE_GLOBAL_DATA_PTR;
>   PAD_CTL_DSE_50ohm | PAD_CTL_OBE_IBE_ENABLE)
>   
>   #define USB_PEN_GPIO   83
>  +#define USB_CDET_GPIO   102
>   
>   static struct ddrmc_cr_setting colibri_vf_cr_settings[] = {
>   /* levelling */
>  @@ -92,6 +94,7 @@ static struct ddrmc_cr_setting 
>  colibri_vf_cr_settings[] = {
>   
>   static const iomux_v3_cfg_t usb_pads[] = {
>   VF610_PAD_PTD4__GPIO_83,
>  +VF610_PAD_PTC29__GPIO_102,
>   };
>   
>   int dram_init(void)
>  @@ -280,7 +283,6 @@ static void setup_iomux_gpio(void)
>   VF610_PAD_PTB23__GPIO_93,
>   VF610_PAD_PTB26__GPIO_96,
>   VF610_PAD_PTB28__GPIO_98,
>  -VF610_PAD_PTC29__GPIO_102,
>   VF610_PAD_PTC30__GPIO_103,
>   VF610_PAD_PTA7__GPIO_134,
>   };
>  @@ -509,6 +511,10 @@ int board_init(void)
>   
>   setbits_le32(>sosc_ctr, SCSC_SOSC_CTR_SOSC_EN);
>   
>  +#ifdef CONFIG_USB_EHCI_VF
>  +gpio_request(USB_CDET_GPIO, "usb-cdet-gpio");
>  +#endif
>  +
>   return 0;
>   }
>   
>  @@ -554,4 +560,29 @@ int board_ehci_hcd_init(int port)
>   }
>   return 0;
>   }
>  +
>  +int board_usb_phy_mode(int port)
>  +{
>  +switch (port) {
>  +case 0:
>  +/*
>  + * Port 0 is used only in client mode on Colibri Vybrid 
>  modules
>  + * Check for state of USB client gpio pin and 
>  accordingly return
>  + * USB_INIT_DEVICE or USB_INIT_HOST.
>  + */
>  +if (gpio_get_value(USB_CDET_GPIO))
>  +return USB_INIT_DEVICE;
>  +else
>  +return USB_INIT_HOST;
>  +case 1:
>  +/* Port 1 is used only in host mode on Colibri Vybrid 
>  modules */
>  +return USB_INIT_HOST;
>  +default:
>  +/*
>  + * There are only two USB controllers on Vybrid. 
>  Ideally we will
>  + * not reach here. However 

Re: [U-Boot] [PATCH v5] colibri_vf: Add board_usb_phy_mode function

[maitysanchayan]

On 15-11-24 11:37:59, Stefano Babic wrote:
> On 24/11/2015 11:23, maitysancha...@gmail.com wrote:
> > Hello,
> > 
> > Ping?
> > 
> > Any further feedback? Is the patchset good to get accepted?
> 
> I'll pick it up

Thanks.

- Sanchayan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5] colibri_vf: Add board_usb_phy_mode function

[maitysanchayan]

Hello,

Ping?

Any further feedback? Is the patchset good to get accepted?

Thanks.

Regards,
Sanchayan.

On 15-11-12 11:47:35, Sanchayan Maity wrote:
> Add board_usb_phy_mode function for detecting whether a port is
> being used as host or client using a GPIO. On Colibri Vybrid we
> provide GPIO 102 for this very same purpose.
> 
> Signed-off-by: Sanchayan Maity 
> ---
> Changes since v4:
> No need to break after return.
> 
> Changes since v3:
> Return USB_INIT_DEVICE or USB_INIT_HOST after checking for
> the GPIO state to account for the fact that the previous
> logic breaks in case if the enum for USB mode were to ever
> be changed.
> 
> Add comments based on Stefan's feedback.
> 
> Changes since v2:
> 
> Instead of returning 0 from board_usb_phy_mode return it as
> USB_INIT_HOST.
> 
> Changes since v1:
> 
> Move the GPIO request call to the board_init function as all
> further calls to board_usb_phy_mode will actually result in the
> gpio_request failing.
> ---
>  board/toradex/colibri_vf/colibri_vf.c | 33 -
>  1 file changed, 32 insertions(+), 1 deletion(-)
> 
> diff --git a/board/toradex/colibri_vf/colibri_vf.c 
> b/board/toradex/colibri_vf/colibri_vf.c
> index a6d1c5b..c65ccb3 100644
> --- a/board/toradex/colibri_vf/colibri_vf.c
> +++ b/board/toradex/colibri_vf/colibri_vf.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> @@ -34,6 +35,7 @@ DECLARE_GLOBAL_DATA_PTR;
>   PAD_CTL_DSE_50ohm | PAD_CTL_OBE_IBE_ENABLE)
>  
>  #define USB_PEN_GPIO   83
> +#define USB_CDET_GPIO102
>  
>  static struct ddrmc_cr_setting colibri_vf_cr_settings[] = {
>   /* levelling */
> @@ -92,6 +94,7 @@ static struct ddrmc_cr_setting colibri_vf_cr_settings[] = {
>  
>  static const iomux_v3_cfg_t usb_pads[] = {
>   VF610_PAD_PTD4__GPIO_83,
> + VF610_PAD_PTC29__GPIO_102,
>  };
>  
>  int dram_init(void)
> @@ -280,7 +283,6 @@ static void setup_iomux_gpio(void)
>   VF610_PAD_PTB23__GPIO_93,
>   VF610_PAD_PTB26__GPIO_96,
>   VF610_PAD_PTB28__GPIO_98,
> - VF610_PAD_PTC29__GPIO_102,
>   VF610_PAD_PTC30__GPIO_103,
>   VF610_PAD_PTA7__GPIO_134,
>   };
> @@ -509,6 +511,10 @@ int board_init(void)
>  
>   setbits_le32(>sosc_ctr, SCSC_SOSC_CTR_SOSC_EN);
>  
> +#ifdef CONFIG_USB_EHCI_VF
> + gpio_request(USB_CDET_GPIO, "usb-cdet-gpio");
> +#endif
> +
>   return 0;
>  }
>  
> @@ -554,4 +560,29 @@ int board_ehci_hcd_init(int port)
>   }
>   return 0;
>  }
> +
> +int board_usb_phy_mode(int port)
> +{
> + switch (port) {
> + case 0:
> + /*
> +  * Port 0 is used only in client mode on Colibri Vybrid modules
> +  * Check for state of USB client gpio pin and accordingly return
> +  * USB_INIT_DEVICE or USB_INIT_HOST.
> +  */
> + if (gpio_get_value(USB_CDET_GPIO))
> + return USB_INIT_DEVICE;
> + else
> + return USB_INIT_HOST;
> + case 1:
> + /* Port 1 is used only in host mode on Colibri Vybrid modules */
> + return USB_INIT_HOST;
> + default:
> + /*
> +  * There are only two USB controllers on Vybrid. Ideally we will
> +  * not reach here. However return USB_INIT_HOST if we do.
> +  */
> + return USB_INIT_HOST;
> + }
> +}
>  #endif
> -- 
> 2.6.2
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] colibri_vf: Add board_usb_phy_mode function

[maitysanchayan]

On 15-10-30 14:20:29, Marek Vasut wrote:
> On Friday, October 30, 2015 at 01:26:59 PM, Sanchayan Maity wrote:
> > Add board_usb_phy_mode function for detecting whether a port is
> > being used as host or client using a GPIO. On Colibri Vybrid we
> > provide the GPIO 102 for this very same purpose.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> > Changes since v1:
> > 
> > Move the GPIO request call to the board_init function as all
> > further calls to board_usb_phy_mode will actually result in the
> > gpio_request failing.
> > 
> > Changes since v2:
> > 
> > Instead of returning 0 from board_usb_phy_mode return it as
> > USB_INIT_HOST.
> > ---
> >  board/toradex/colibri_vf/colibri_vf.c | 23 ++-
> >  1 file changed, 22 insertions(+), 1 deletion(-)
> > 
> > diff --git a/board/toradex/colibri_vf/colibri_vf.c
> > b/board/toradex/colibri_vf/colibri_vf.c index a6d1c5b..9878671 100644
> > --- a/board/toradex/colibri_vf/colibri_vf.c
> > +++ b/board/toradex/colibri_vf/colibri_vf.c
> > @@ -21,6 +21,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > 
> >  DECLARE_GLOBAL_DATA_PTR;
> > 
> > @@ -34,6 +35,7 @@ DECLARE_GLOBAL_DATA_PTR;
> > PAD_CTL_DSE_50ohm | PAD_CTL_OBE_IBE_ENABLE)
> > 
> >  #define USB_PEN_GPIO   83
> > +#define USB_CDET_GPIO  102
> > 
> >  static struct ddrmc_cr_setting colibri_vf_cr_settings[] = {
> > /* levelling */
> > @@ -92,6 +94,7 @@ static struct ddrmc_cr_setting colibri_vf_cr_settings[] =
> > {
> > 
> >  static const iomux_v3_cfg_t usb_pads[] = {
> > VF610_PAD_PTD4__GPIO_83,
> > +   VF610_PAD_PTC29__GPIO_102,
> >  };
> > 
> >  int dram_init(void)
> > @@ -280,7 +283,6 @@ static void setup_iomux_gpio(void)
> > VF610_PAD_PTB23__GPIO_93,
> > VF610_PAD_PTB26__GPIO_96,
> > VF610_PAD_PTB28__GPIO_98,
> > -   VF610_PAD_PTC29__GPIO_102,
> > VF610_PAD_PTC30__GPIO_103,
> > VF610_PAD_PTA7__GPIO_134,
> > };
> > @@ -509,6 +511,10 @@ int board_init(void)
> > 
> > setbits_le32(>sosc_ctr, SCSC_SOSC_CTR_SOSC_EN);
> > 
> > +#ifdef CONFIG_USB_EHCI_VF
> > +   gpio_request(USB_CDET_GPIO, "usb-cdet-gpio");
> > +#endif
> > +
> > return 0;
> >  }
> > 
> > @@ -554,4 +560,19 @@ int board_ehci_hcd_init(int port)
> > }
> > return 0;
> >  }
> > +
> > +int board_usb_phy_mode(int port)
> > +{
> > +   switch (port) {
> > +   case 0:
> > +   return gpio_get_value(USB_CDET_GPIO);
> 
> So what would happen to this code in case we re-number the USB_INIT_HOST
> and USB_INIT_DEVICE or in case the GPIO API starts returning something
> else but 0 or 1 here ?

Sorry for the delay in reply. Had got tied up elsewhere.

Currently USB_INIT_HOST and USB_INIT_DEVICE are defined with an enum. If we
were to switch this would not work as I intended. I guess this would be
more appropriate then

if (gpio_get_value(USB_CDET_GPIO))
return USB_INIT_DEVICE;
else
return USB_INIT_HOST;

For the GPIO, isn't gpio_get_value always suppose to return the actual state
of GPIO? Would we ever change the GPIO API to report otherwise?

Concerning the other thread from Stefan's query I will add the comments.

Thanks.

- Sanchayan.

> 
> > +   break;
> > +   case 1:
> > +   return USB_INIT_HOST;
> > +   break;
> > +   default:
> > +   return USB_INIT_HOST;
> > +   break;
> > +   }
> > +}
> >  #endif
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] colibri_vf: Add board_usb_phy_mode function

[maitysanchayan]

On 15-10-27 10:18:47, Marek Vasut wrote:
> On Monday, October 26, 2015 at 01:58:51 PM, Sanchayan Maity wrote:
> > Add board_usb_phy_mode function for detecting whether a port is
> > being used as host or client using a GPIO. On Colibri Vybrid we
> > provide the GPIO 102 for the very same purpose.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  board/toradex/colibri_vf/colibri_vf.c | 19 ++-
> >  1 file changed, 18 insertions(+), 1 deletion(-)
> > 
> > diff --git a/board/toradex/colibri_vf/colibri_vf.c
> > b/board/toradex/colibri_vf/colibri_vf.c index a6d1c5b..fd90ef2 100644
> > --- a/board/toradex/colibri_vf/colibri_vf.c
> > +++ b/board/toradex/colibri_vf/colibri_vf.c
> > @@ -34,6 +34,7 @@ DECLARE_GLOBAL_DATA_PTR;
> > PAD_CTL_DSE_50ohm | PAD_CTL_OBE_IBE_ENABLE)
> > 
> >  #define USB_PEN_GPIO   83
> > +#define USB_CDET_GPIO  102
> > 
> >  static struct ddrmc_cr_setting colibri_vf_cr_settings[] = {
> > /* levelling */
> > @@ -92,6 +93,7 @@ static struct ddrmc_cr_setting colibri_vf_cr_settings[] =
> > {
> > 
> >  static const iomux_v3_cfg_t usb_pads[] = {
> > VF610_PAD_PTD4__GPIO_83,
> > +   VF610_PAD_PTC29__GPIO_102,
> >  };
> > 
> >  int dram_init(void)
> > @@ -280,7 +282,6 @@ static void setup_iomux_gpio(void)
> > VF610_PAD_PTB23__GPIO_93,
> > VF610_PAD_PTB26__GPIO_96,
> > VF610_PAD_PTB28__GPIO_98,
> > -   VF610_PAD_PTC29__GPIO_102,
> > VF610_PAD_PTC30__GPIO_103,
> > VF610_PAD_PTA7__GPIO_134,
> > };
> > @@ -554,4 +555,20 @@ int board_ehci_hcd_init(int port)
> > }
> > return 0;
> >  }
> > +
> > +int board_usb_phy_mode(int port)
> > +{
> > +   switch (port) {
> > +   case 0:
> > +   gpio_request(USB_CDET_GPIO, "usb-cdet-gpio");
> 
> The gpio_request() here will fail the second time you do "usb reset" on
> the command line I think. You might want to request this elsewhere.

Hmmm makes sense. I did not try usb reset. Only usb start stop and dfu cmds.
Will check and revert back accordingly.

Thanks.

- Sanchayan.

>
> > +   return gpio_get_value(USB_CDET_GPIO);
> > +   break;
> > +   case 1:
> > +   return 0;
> > +   break;
> > +   default:
> > +   return 0;
> > +   break;
> > +   }
> > +}
> >  #endif
> 
> Best regards,
> Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] usb: host: ehci-vf: Remove hardcoded USB host client configuration

[maitysanchayan]

Hello,

On 15-10-26 20:19:42, Marek Vasut wrote:
> On Monday, October 26, 2015 at 01:58:49 PM, Sanchayan Maity wrote:
> > The current ehci-vf USB driver for Vybrid hardcodes the USB host
> > and client functionality. Remove this.
> > 
> > Reported-by: Santhosh Kumar Janardhanam 
> > Signed-off-by: Sanchayan Maity 
> 
> Is this a V2 or why did I receive this patchset twice ?

Yes sorry about that. I specified the uboot mailing list address wrong
in my first patchset mail. Had to resend but then missed adding RESEND.

- Sanchayan.

>
> Looks OK though.
> 
> Best regards,
> Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Doubt in USB driver for Vybrid vf610

[maitysanchayan]

Hello,

On 15-10-24 12:09:43, Fabio Estevam wrote:
> Hi Marek,
> 
> On Fri, Oct 23, 2015 at 4:23 PM, Marek Vasut  wrote:
> 
> >> Any inputs on the below?
> >
> > I don't have a Vybrid device, CCing Fabio.
> 
> I don't have access to a Vybrid board either.
> 
> Sanchayan,
> 
> Does drivers/usb/host/ehci-mx6.c behave the same way?

No.

I included the particular piece of code below


if (init == USB_INIT_DEVICE && index == 1)
return -ENODEV;
if (init == USB_INIT_HOST && index == 0)
return -ENODEV;

in the ehci-vf driver because our requirement was to have one port
as client and other as host. Since on USB start both ports get configured
as host as it iterates depending on USB EHCI controller count, the above
was meant to stop the port required as client to be configured as host and
vice versa while using client functionality such as DFU.

I made the mistake of not thinking that this is not a generic use case,
someone might want it the other way around or such.

So coming to the main question, what would be the correct way to fix this?
I tested that even if the above four lines are removed and USB start configures
both ports as host, calling dfu later will still result in correct functioning.
So is this ok and the four lines should be nuked or a more appropriate way would
be to add something like board_ehci_hcd_init_with_type(int index, enum usb_init
_type init) which would be a weak function and have the board specific code call
this to do the above which is currently done in ehci-vf.

I wasn't sure about the right approach to take so I asked.

Thanks & Regards,
Sanchayan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Doubt in USB driver for Vybrid vf610

[maitysanchayan]

On 15-10-24 18:08:53, Marek Vasut wrote:
> On Saturday, October 24, 2015 at 05:23:05 PM, maitysancha...@gmail.com wrote:
> > Hello,
> > 
> > On 15-10-24 12:09:43, Fabio Estevam wrote:
> > > Hi Marek,
> > > 
> > > On Fri, Oct 23, 2015 at 4:23 PM, Marek Vasut  wrote:
> > > >> Any inputs on the below?
> > > > 
> > > > I don't have a Vybrid device, CCing Fabio.
> > > 
> > > I don't have access to a Vybrid board either.
> > > 
> > > Sanchayan,
> > > 
> > > Does drivers/usb/host/ehci-mx6.c behave the same way?
> > 
> > No.
> > 
> > I included the particular piece of code below
> > 
> > 
> > if (init == USB_INIT_DEVICE && index == 1)
> > return -ENODEV;
> > if (init == USB_INIT_HOST && index == 0)
> > return -ENODEV;
> > 
> > in the ehci-vf driver because our requirement was to have one port
> > as client and other as host. Since on USB start both ports get configured
> > as host as it iterates depending on USB EHCI controller count, the above
> > was meant to stop the port required as client to be configured as host and
> > vice versa while using client functionality such as DFU.
> > 
> > I made the mistake of not thinking that this is not a generic use case,
> > someone might want it the other way around or such.
> >
> > So coming to the main question, what would be the correct way to fix this?
> > I tested that even if the above four lines are removed and USB start
> > configures both ports as host, calling dfu later will still result in
> > correct functioning. So is this ok and the four lines should be nuked or a
> > more appropriate way would be to add something like
> > board_ehci_hcd_init_with_type(int index, enum usb_init _type init) which
> > would be a weak function and have the board specific code call this to do
> > the above which is currently done in ehci-vf.
> > 
> > I wasn't sure about the right approach to take so I asked.
> 
> Brief glare over the driver tells me that those four lines are complete 
> nonsense
> and should be removed.

Yes very much so. But is removing just ok or it would be better to actually
restrict as per a board's requirement what gets configured as host and what
gets configured as client by adding the weak function hook I was talking
about?

- Sanchayan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Doubt in USB driver for Vybrid vf610

[maitysanchayan]

On 15-10-24 18:16:20, Marek Vasut wrote:
> On Saturday, October 24, 2015 at 06:08:57 PM, maitysancha...@gmail.com wrote:
> > On 15-10-24 18:08:53, Marek Vasut wrote:
> > > On Saturday, October 24, 2015 at 05:23:05 PM, maitysancha...@gmail.com 
> wrote:
> > > > Hello,
> > > > 
> > > > On 15-10-24 12:09:43, Fabio Estevam wrote:
> > > > > Hi Marek,
> > > > > 
> > > > > On Fri, Oct 23, 2015 at 4:23 PM, Marek Vasut  wrote:
> > > > > >> Any inputs on the below?
> > > > > > 
> > > > > > I don't have a Vybrid device, CCing Fabio.
> > > > > 
> > > > > I don't have access to a Vybrid board either.
> > > > > 
> > > > > Sanchayan,
> > > > > 
> > > > > Does drivers/usb/host/ehci-mx6.c behave the same way?
> > > > 
> > > > No.
> > > > 
> > > > I included the particular piece of code below
> > > > 
> > > > if (init == USB_INIT_DEVICE && index == 1)
> > > > 
> > > > return -ENODEV;
> > > > 
> > > > if (init == USB_INIT_HOST && index == 0)
> > > > 
> > > > return -ENODEV;
> > > > 
> > > > in the ehci-vf driver because our requirement was to have one port
> > > > as client and other as host. Since on USB start both ports get
> > > > configured as host as it iterates depending on USB EHCI controller
> > > > count, the above was meant to stop the port required as client to be
> > > > configured as host and vice versa while using client functionality
> > > > such as DFU.
> > > > 
> > > > I made the mistake of not thinking that this is not a generic use case,
> > > > someone might want it the other way around or such.
> > > > 
> > > > So coming to the main question, what would be the correct way to fix
> > > > this? I tested that even if the above four lines are removed and USB
> > > > start configures both ports as host, calling dfu later will still
> > > > result in correct functioning. So is this ok and the four lines should
> > > > be nuked or a more appropriate way would be to add something like
> > > > board_ehci_hcd_init_with_type(int index, enum usb_init _type init)
> > > > which would be a weak function and have the board specific code call
> > > > this to do the above which is currently done in ehci-vf.
> > > > 
> > > > I wasn't sure about the right approach to take so I asked.
> > > 
> > > Brief glare over the driver tells me that those four lines are complete
> > > nonsense and should be removed.
> > 
> > Yes very much so. But is removing just ok or it would be better to actually
> > restrict as per a board's requirement what gets configured as host and what
> > gets configured as client by adding the weak function hook I was talking
> > about?
> 
> The mx6 ones does board_usb_phy_mode() to determine this restriction. But (!)
> it'd be even better if this information was obtained from DT. It'd be nice
> if someone started working on converting i.MX to DT.

Yes, that's how iMX6 does it. However note that Vybrid USB is not a true OTG.

I quote the Vybrid TRM here,

"The USB is not a true OTG. It can be configured by software to function either
as a peripheral or as host. The ID pin, which is unique for OTG operation, is
not present in this implementation. There are no five pin interface. The user
will get four pin host/device interface."

As per 44.2.1.2 of the Vybrid TRM.

- Sanchayan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Doubt in USB driver for Vybrid vf610

[maitysanchayan]

On 15-10-24 19:50:13, Marek Vasut wrote:
> On Saturday, October 24, 2015 at 06:23:44 PM, maitysancha...@gmail.com wrote:
> > On 15-10-24 18:16:20, Marek Vasut wrote:
> > > On Saturday, October 24, 2015 at 06:08:57 PM, maitysancha...@gmail.com 
> wrote:
> > > > On 15-10-24 18:08:53, Marek Vasut wrote:
> > > > > On Saturday, October 24, 2015 at 05:23:05 PM,
> > > > > maitysancha...@gmail.com
> > > 
> > > wrote:
> > > > > > Hello,
> > > > > > 
> > > > > > On 15-10-24 12:09:43, Fabio Estevam wrote:
> > > > > > > Hi Marek,
> > > > > > > 
> > > > > > > On Fri, Oct 23, 2015 at 4:23 PM, Marek Vasut  
> > > > > > > wrote:
> > > > > > > >> Any inputs on the below?
> > > > > > > > 
> > > > > > > > I don't have a Vybrid device, CCing Fabio.
> > > > > > > 
> > > > > > > I don't have access to a Vybrid board either.
> > > > > > > 
> > > > > > > Sanchayan,
> > > > > > > 
> > > > > > > Does drivers/usb/host/ehci-mx6.c behave the same way?
> > > > > > 
> > > > > > No.
> > > > > > 
> > > > > > I included the particular piece of code below
> > > > > > 
> > > > > > if (init == USB_INIT_DEVICE && index == 1)
> > > > > > 
> > > > > > return -ENODEV;
> > > > > > 
> > > > > > if (init == USB_INIT_HOST && index == 0)
> > > > > > 
> > > > > > return -ENODEV;
> > > > > > 
> > > > > > in the ehci-vf driver because our requirement was to have one port
> > > > > > as client and other as host. Since on USB start both ports get
> > > > > > configured as host as it iterates depending on USB EHCI controller
> > > > > > count, the above was meant to stop the port required as client to
> > > > > > be configured as host and vice versa while using client
> > > > > > functionality such as DFU.
> > > > > > 
> > > > > > I made the mistake of not thinking that this is not a generic use
> > > > > > case, someone might want it the other way around or such.
> > > > > > 
> > > > > > So coming to the main question, what would be the correct way to
> > > > > > fix this? I tested that even if the above four lines are removed
> > > > > > and USB start configures both ports as host, calling dfu later
> > > > > > will still result in correct functioning. So is this ok and the
> > > > > > four lines should be nuked or a more appropriate way would be to
> > > > > > add something like board_ehci_hcd_init_with_type(int index, enum
> > > > > > usb_init _type init) which would be a weak function and have the
> > > > > > board specific code call this to do the above which is currently
> > > > > > done in ehci-vf.
> > > > > > 
> > > > > > I wasn't sure about the right approach to take so I asked.
> > > > > 
> > > > > Brief glare over the driver tells me that those four lines are
> > > > > complete nonsense and should be removed.
> > > > 
> > > > Yes very much so. But is removing just ok or it would be better to
> > > > actually restrict as per a board's requirement what gets configured as
> > > > host and what gets configured as client by adding the weak function
> > > > hook I was talking about?
> > > 
> > > The mx6 ones does board_usb_phy_mode() to determine this restriction. But
> > > (!) it'd be even better if this information was obtained from DT. It'd
> > > be nice if someone started working on converting i.MX to DT.
> > 
> > Yes, that's how iMX6 does it. However note that Vybrid USB is not a true
> > OTG.
> > 
> > I quote the Vybrid TRM here,
> > 
> > "The USB is not a true OTG. It can be configured by software to function
> > either as a peripheral or as host. The ID pin, which is unique for OTG
> > operation, is not present in this implementation. There are no five pin
> > interface. The user will get four pin host/device interface."
> 
> Can't the user use a GPIO instead of dedicated OTG switch pin ?

Yes. In fact in Linux we use the extcon framework along with the GPIO to have
automatic switch over between client and host.

I will send a patch by Monday to remove the incorrect code. Will later send
a patch to incoporate the correct fix. Since all boards might not have a GPIO
to do this I had not considered this option but if this is acceptable it is
fine by me.

Thanks.

- Sanchayan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Doubt in USB driver for Vybrid vf610

[maitysanchayan]

Hello Marek,

Any inputs on the below?

Thanks & Regards,
Sanchayan Maity.

On 15-10-19 10:58:47, maitysancha...@gmail.com wrote:
> Hello Marek,
> 
> On 15-10-17 21:59:07, maitysancha...@gmail.com wrote:
> > Hello,
> > 
> > On 15-10-16 16:20:07, Santhosh Kumar Janardhanam -ERS, HCL Tech wrote:
> > > Hi All,
> > > I am working on USB part for vybrid vf-610 processor, We have two ports 
> > > in the board
> > > 
> > > when I type usb start in uboot command prompt, It returns as ENODEV for 
> > > USB0 and when analyzed, It is returning from the below code in 
> > > ehci-hcd_init function(in ehci-vf.c)
> > > 
> > > if (init == USB_INIT_HOST && index == 0)
> > > return -ENODEV;
> > > 
> 
> Along with the above
> if (init == USB_INIT_DEVICE && index == 1)
>   return -ENODEV;
> 
> In the ehci-vf USB driver for Vybrid, currently we have two "if" cases as 
> above which basically
> serve the purpose of preventing one of the USB ports from being configured as 
> host, which we
> did like to keep as client. So for us, USB0 is client and USB1 is host and 
> the above was put
> in with that intention to prevent USB0 from being configured as host, when 
> usb start is called.
> However this is bad for other users out there, sorry about that.
> 
> I checked and it seems even without the above, if both ports are configured 
> as host with usb
> start and later dfu is called to used the intended as client for upgrade 
> purposes, things still
> seem to work. Not sure if there are cases where this can break which I am 
> missing.
> 
> Not being that well versed with USB I wanted to ask is this ok or this is 
> completely wrong?
> If it is ok, I guess we can go ahead and nuke the above checks? OR will be it 
> be a better
> approach to introduce something like board_ehci_hch_init_with_type(int index, 
> enum usb_init_type type)
> which will be a weak function and then have the board specific code hook call 
> it?
> 
> - Sanchayan.
> 
> > >  If these two  lines are commented, the usb start is working and device 
> > > is found on USB0.
> > > Why is this check kept in the code? 
> > 
> > I am the author of the ehci-vf USB driver which is based on iMX6 
> > implementation.
> > The implementation was done as per our requirements where we have one port 
> > as
> > host and another as client. In hindsight my implementation is severely 
> > restricting
> > and at that time I missed thinking of it and did not had other boards to 
> > test.
> > 
> > I will fix this up and send a patch. However I need to look a bit. The 
> > ideal way
> > would be to fix it up in board_ehci_hcd_init call however that does not 
> > provide
> > the init parameter to distinguish between USB_INIT_DEVICE and USB_INIT_HOST.
> > 
> > May I ask are you using some module or you have your custom setup around the
> > Vybrid? Sorry for the trouble. Thanks for reporting.
> > 
> > - Sanchayan.
> > 
> > >
> > > Regards,
> > > Santhosh
> > > 
> > > 
> > > ::DISCLAIMER::
> > > 
> > > 
> > > The contents of this e-mail and any attachment(s) are confidential and 
> > > intended for the named recipient(s) only.
> > > E-mail transmission is not guaranteed to be secure or error-free as 
> > > information could be intercepted, corrupted,
> > > lost, destroyed, arrive late or incomplete, or may contain viruses in 
> > > transmission. The e mail and its contents
> > > (with or without referred errors) shall therefore not attach any 
> > > liability on the originator or HCL or its affiliates.
> > > Views or opinions, if any, presented in this email are solely those of 
> > > the author and may not necessarily reflect the
> > > views or opinions of HCL or its affiliates. Any form of reproduction, 
> > > dissemination, copying, disclosure, modification,
> > > distribution and / or publication of this message without the prior 
> > > written consent of authorized representative of
> > > HCL is strictly prohibited. If you have received this email in error 
> > > please delete it and notify the sender immediately.
> > > Before opening any email and/or attachments, please check them for 
> > > viruses and other defects.
> > > 
> > > 
> > > 
> > > ___
> > > U-Boot mailing list
> > > U-Boot@lists.denx.de
> > > http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Doubt in USB driver for Vybrid vf610

[maitysanchayan]

Hello Marek,

On 15-10-17 21:59:07, maitysancha...@gmail.com wrote:
> Hello,
> 
> On 15-10-16 16:20:07, Santhosh Kumar Janardhanam -ERS, HCL Tech wrote:
> > Hi All,
> > I am working on USB part for vybrid vf-610 processor, We have two ports in 
> > the board
> > 
> > when I type usb start in uboot command prompt, It returns as ENODEV for 
> > USB0 and when analyzed, It is returning from the below code in 
> > ehci-hcd_init function(in ehci-vf.c)
> > 
> > if (init == USB_INIT_HOST && index == 0)
> > return -ENODEV;
> > 

Along with the above
if (init == USB_INIT_DEVICE && index == 1)
return -ENODEV;

In the ehci-vf USB driver for Vybrid, currently we have two "if" cases as above 
which basically
serve the purpose of preventing one of the USB ports from being configured as 
host, which we
did like to keep as client. So for us, USB0 is client and USB1 is host and the 
above was put
in with that intention to prevent USB0 from being configured as host, when usb 
start is called.
However this is bad for other users out there, sorry about that.

I checked and it seems even without the above, if both ports are configured as 
host with usb
start and later dfu is called to used the intended as client for upgrade 
purposes, things still
seem to work. Not sure if there are cases where this can break which I am 
missing.

Not being that well versed with USB I wanted to ask is this ok or this is 
completely wrong?
If it is ok, I guess we can go ahead and nuke the above checks? OR will be it 
be a better
approach to introduce something like board_ehci_hch_init_with_type(int index, 
enum usb_init_type type)
which will be a weak function and then have the board specific code hook call 
it?

- Sanchayan.

> >  If these two  lines are commented, the usb start is working and device is 
> > found on USB0.
> > Why is this check kept in the code? 
> 
> I am the author of the ehci-vf USB driver which is based on iMX6 
> implementation.
> The implementation was done as per our requirements where we have one port as
> host and another as client. In hindsight my implementation is severely 
> restricting
> and at that time I missed thinking of it and did not had other boards to test.
> 
> I will fix this up and send a patch. However I need to look a bit. The ideal 
> way
> would be to fix it up in board_ehci_hcd_init call however that does not 
> provide
> the init parameter to distinguish between USB_INIT_DEVICE and USB_INIT_HOST.
> 
> May I ask are you using some module or you have your custom setup around the
> Vybrid? Sorry for the trouble. Thanks for reporting.
> 
> - Sanchayan.
> 
> >
> > Regards,
> > Santhosh
> > 
> > 
> > ::DISCLAIMER::
> > 
> > 
> > The contents of this e-mail and any attachment(s) are confidential and 
> > intended for the named recipient(s) only.
> > E-mail transmission is not guaranteed to be secure or error-free as 
> > information could be intercepted, corrupted,
> > lost, destroyed, arrive late or incomplete, or may contain viruses in 
> > transmission. The e mail and its contents
> > (with or without referred errors) shall therefore not attach any liability 
> > on the originator or HCL or its affiliates.
> > Views or opinions, if any, presented in this email are solely those of the 
> > author and may not necessarily reflect the
> > views or opinions of HCL or its affiliates. Any form of reproduction, 
> > dissemination, copying, disclosure, modification,
> > distribution and / or publication of this message without the prior written 
> > consent of authorized representative of
> > HCL is strictly prohibited. If you have received this email in error please 
> > delete it and notify the sender immediately.
> > Before opening any email and/or attachments, please check them for viruses 
> > and other defects.
> > 
> > 
> > 
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Doubt in USB driver for Vybrid vf610

[maitysanchayan]

Hello,

On 15-10-16 16:20:07, Santhosh Kumar Janardhanam -ERS, HCL Tech wrote:
> Hi All,
> I am working on USB part for vybrid vf-610 processor, We have two ports in 
> the board
> 
> when I type usb start in uboot command prompt, It returns as ENODEV for USB0 
> and when analyzed, It is returning from the below code in ehci-hcd_init 
> function(in ehci-vf.c)
> 
> if (init == USB_INIT_HOST && index == 0)
> return -ENODEV;
> 
>  If these two  lines are commented, the usb start is working and device is 
> found on USB0. 
> Why is this check kept in the code? 

I am the author of the ehci-vf USB driver which is based on iMX6 implementation.
The implementation was done as per our requirements where we have one port as
host and another as client. In hindsight my implementation is severely 
restricting
and at that time I missed thinking of it and did not had other boards to test.

I will fix this up and send a patch. However I need to look a bit. The ideal way
would be to fix it up in board_ehci_hcd_init call however that does not provide
the init parameter to distinguish between USB_INIT_DEVICE and USB_INIT_HOST.

May I ask are you using some module or you have your custom setup around the
Vybrid? Sorry for the trouble. Thanks for reporting.

- Sanchayan.

>
> Regards,
> Santhosh
> 
> 
> ::DISCLAIMER::
> 
> 
> The contents of this e-mail and any attachment(s) are confidential and 
> intended for the named recipient(s) only.
> E-mail transmission is not guaranteed to be secure or error-free as 
> information could be intercepted, corrupted,
> lost, destroyed, arrive late or incomplete, or may contain viruses in 
> transmission. The e mail and its contents
> (with or without referred errors) shall therefore not attach any liability on 
> the originator or HCL or its affiliates.
> Views or opinions, if any, presented in this email are solely those of the 
> author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction, 
> dissemination, copying, disclosure, modification,
> distribution and / or publication of this message without the prior written 
> consent of authorized representative of
> HCL is strictly prohibited. If you have received this email in error please 
> delete it and notify the sender immediately.
> Before opening any email and/or attachments, please check them for viruses 
> and other defects.
> 
> 
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] colibri_vf: Increase console IO buffer size to 1024

[maitysanchayan]

On 15-07-02 09:26:04, Stefano Babic wrote:
 Hi Sanchayan,
 
 I merge it.

Thanks Stefano.

- Sanchayan.

 
 On 02/07/2015 07:56, maitysancha...@gmail.com wrote:
  Hello,
  
  Another ping?
  
  - Sanchayan.
  
  On 15-06-08 12:40:41, Sanchayan Maity wrote:
  Increase console IO buffer size to 1024 from the previous value of 256.
  The previous value was too short for editing environment variables like
  ubiboot from the console.
 
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
   include/configs/colibri_vf.h | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
 
  diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h
  index ace31a5..17418c6 100644
  --- a/include/configs/colibri_vf.h
  +++ b/include/configs/colibri_vf.h
  @@ -183,7 +183,7 @@
   #define CONFIG_SYS_PROMPT_HUSH_PS2 
   #define CONFIG_SYS_PROMPT Colibri VFxx # 
   #undef CONFIG_AUTO_COMPLETE
  -#define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */
  +#define CONFIG_SYS_CBSIZE 1024/* Console I/O Buffer Size */
   #define CONFIG_SYS_PBSIZE \
 (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16)
   #define CONFIG_SYS_MAXARGS16  /* max number of 
  command args */
  -- 
  2.4.2
 
 
 Regards,
 Stefano
 
 -- 
 =
 DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
 HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
 Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
 =
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] colibri_vf: Increase console IO buffer size to 1024

[maitysanchayan]

Hello,

Another ping?

- Sanchayan.

On 15-06-08 12:40:41, Sanchayan Maity wrote:
 Increase console IO buffer size to 1024 from the previous value of 256.
 The previous value was too short for editing environment variables like
 ubiboot from the console.
 
 Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
 ---
  include/configs/colibri_vf.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h
 index ace31a5..17418c6 100644
 --- a/include/configs/colibri_vf.h
 +++ b/include/configs/colibri_vf.h
 @@ -183,7 +183,7 @@
  #define CONFIG_SYS_PROMPT_HUSH_PS2
  #define CONFIG_SYS_PROMPTColibri VFxx # 
  #undef CONFIG_AUTO_COMPLETE
 -#define CONFIG_SYS_CBSIZE256 /* Console I/O Buffer Size */
 +#define CONFIG_SYS_CBSIZE1024/* Console I/O Buffer Size */
  #define CONFIG_SYS_PBSIZE\
   (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16)
  #define CONFIG_SYS_MAXARGS   16  /* max number of command args */
 -- 
 2.4.2
 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] colibri_vf: Increase console IO buffer size to 1024

[maitysanchayan]

Hello,

Ping.

- Sanchayan.

On 15-06-08 12:40:41, Sanchayan Maity wrote:
 Increase console IO buffer size to 1024 from the previous value of 256.
 The previous value was too short for editing environment variables like
 ubiboot from the console.
 
 Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
 ---
  include/configs/colibri_vf.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h
 index ace31a5..17418c6 100644
 --- a/include/configs/colibri_vf.h
 +++ b/include/configs/colibri_vf.h
 @@ -183,7 +183,7 @@
  #define CONFIG_SYS_PROMPT_HUSH_PS2
  #define CONFIG_SYS_PROMPTColibri VFxx # 
  #undef CONFIG_AUTO_COMPLETE
 -#define CONFIG_SYS_CBSIZE256 /* Console I/O Buffer Size */
 +#define CONFIG_SYS_CBSIZE1024/* Console I/O Buffer Size */
  #define CONFIG_SYS_PBSIZE\
   (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16)
  #define CONFIG_SYS_MAXARGS   16  /* max number of command args */
 -- 
 2.4.2
 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Query on weak function for board specific initialisation

[maitysanchayan]

Hello Jeroen,

On 15-05-30 16:44:32, Jeroen Hofstee wrote:
 Hello Maity,
 
 On 30-04-15 14:57, maitysancha...@gmail.com wrote:
 Hello,
 
 I am trying to use a weak function in able to provide a board specific
 initialisation. To be more specific, I am trying to use the __weak
 board_ehci_hcd_init function in the usb driver code which is called in
 ehci_hcd_init, the strong function being defined in the board file.
 This is on lines similar to what I see in the ehci-mx6 driver and some
 mx6 board files like nitrogen's.
 
 Getting a linker error on compiling which is perplexing me at the
 moment.
 
 [snip]
 drivers/usb/host/built-in.o: In function `ehci_hcd_init':
 /home/sanchayan/uboot/u-boot/drivers/usb/host/ehci-vf.c:185:
 undefined reference to `board_echi_hcd_init'
 /home/sanchayan/gcc-linaro/bin/arm-linux-gnueabihf-ld.bfd: BFD
 (crosstool-NG linaro-1.13.1-2012.09-20120921 - Linaro GCC 2012.09) 2.22
 assertion fail
 /cbuild/slaves/oort14/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/src/binutils-2.22/bfd/elf32-arm.c:7498
 /home/sanchayan/gcc-linaro/bin/arm-linux-gnueabihf-ld.bfd: BFD
 (crosstool-NG linaro-1.13.1-2012.09-20120921 - Linaro GCC 2012.09) 2.22
 assertion fail
 /cbuild/slaves/oort14/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/src/binutils-2.22/bfd/elf32-arm.c:13830
 /bin/sh: line 1:  1110 Segmentation fault  (core dumped)
 
 Perhaps I am overlooking something trivial?
 
 
 I suppose you found this already, but for completeness, you made a typo:
 
 board_ehci_hcd_init
 board_echi_hcd_init
 
 To prevent trouble like this, the compiler should actually be set to warn
 if there is no prototype...

Yes, I found the error and also posted the patch. Thanks for the tip, I do
not have that switch turned on, will do so. Lack of sleep and resulting
lack of attention to detail resulted in the trivial noise post :).
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 10/11] usb: ehci-vf: Add weak function for board specific initialisation

[maitysanchayan]

Hello Marek,

On 15-05-18 19:09:58, Marek Vasut wrote:
 On Monday, May 18, 2015 at 03:06:28 PM, Bhuvanchandra DV wrote:
  From: Sanchayan Maity maitysancha...@gmail.com
  
  Add a weak function board_ehci_hcd_init which can be used by the board
  file for board specific initialisation.
  
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
 
 Acked-by: Marek Vasut ma...@denx.de
 
 What I do not like is that you're sending a patch series which affects
 multiple subsystems and which contains patches which should go through
 multiple trees. Yet, you submit it all in one huge series.

If required I can send in the last two patches affecting the USB 
susbsystem later once the rest of the patchset gets merged, if this is 
not acceptable?.

Since these last two were dependent on the GPIO patches I thought 
perhaps it is better that they go along with the GPIO patches as a 
coherent whole.

 
 I guess the best way out of this is to push all this stuff via u-boot-imx now?
 
 Best regards,
 Marek Vasut

Thanks  Regards,
Sanchayan Maity.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Query on weak function for board specific initialisation

[maitysanchayan]

Hello,

I am trying to use a weak function in able to provide a board specific
initialisation. To be more specific, I am trying to use the __weak
board_ehci_hcd_init function in the usb driver code which is called in
ehci_hcd_init, the strong function being defined in the board file.
This is on lines similar to what I see in the ehci-mx6 driver and some
mx6 board files like nitrogen's.

Getting a linker error on compiling which is perplexing me at the
moment.

[snip]
drivers/usb/host/built-in.o: In function `ehci_hcd_init':
/home/sanchayan/uboot/u-boot/drivers/usb/host/ehci-vf.c:185:
undefined reference to `board_echi_hcd_init'
/home/sanchayan/gcc-linaro/bin/arm-linux-gnueabihf-ld.bfd: BFD
(crosstool-NG linaro-1.13.1-2012.09-20120921 - Linaro GCC 2012.09) 2.22
assertion fail
/cbuild/slaves/oort14/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/src/binutils-2.22/bfd/elf32-arm.c:7498
/home/sanchayan/gcc-linaro/bin/arm-linux-gnueabihf-ld.bfd: BFD
(crosstool-NG linaro-1.13.1-2012.09-20120921 - Linaro GCC 2012.09) 2.22
assertion fail
/cbuild/slaves/oort14/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/src/binutils-2.22/bfd/elf32-arm.c:13830
/bin/sh: line 1:  1110 Segmentation fault  (core dumped)

Perhaps I am overlooking something trivial? A diff is attached, the
changes are minimal. I am using our local branch of uboot at 2015.04 and
the gcc linaro toolchain.

Thanks  Regards,
Sanchayan Maity.
diff --git a/arch/arm/include/asm/arch-vf610/iomux-vf610.h b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
index d9257ae..294513c 100644
--- a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
+++ b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
@@ -109,6 +109,7 @@ enum {
 	VF610_PAD_PTD18__NF_IO2			= IOMUX_PAD(0x0130, 0x0130, 2, __NA_, 0, VF610_NFC_IO_PAD_CTRL), 
 	VF610_PAD_PTD17__NF_IO1			= IOMUX_PAD(0x0134, 0x0134, 2, __NA_, 0, VF610_NFC_IO_PAD_CTRL),
 	VF610_PAD_PTD16__NF_IO0			= IOMUX_PAD(0x0138, 0x0138, 2, __NA_, 0, VF610_NFC_IO_PAD_CTRL),
+	VF610_PAD_PTD4__GPIO_83 = IOMUX_PAD(0x014C, 0x014C, 0, __NA_, 0, VF610_GPIO_PAD_CTRL),
 	VF610_PAD_PTB24__NF_WE_B		= IOMUX_PAD(0x0178, 0x0178, 5, __NA_, 0, VF610_NFC_CN_PAD_CTRL),
 	VF610_PAD_PTB25__NF_CE0_B		= IOMUX_PAD(0x017c, 0x017c, 5, __NA_, 0, VF610_NFC_CN_PAD_CTRL),
 
diff --git a/board/toradex/colibri_vf/colibri_vf.c b/board/toradex/colibri_vf/colibri_vf.c
index 59c8c5b..1554ac7 100644
--- a/board/toradex/colibri_vf/colibri_vf.c
+++ b/board/toradex/colibri_vf/colibri_vf.c
@@ -24,6 +24,7 @@
 #include i2c.h
 #include g_dnl.h
 #include asm/gpio.h
+#include usb/ehci-fsl.h
 
 #include ../common/configblock.h
 
@@ -38,6 +39,12 @@ DECLARE_GLOBAL_DATA_PTR;
 #define ENET_PAD_CTRL	(PAD_CTL_PUS_47K_UP | PAD_CTL_SPEED_HIGH | \
 			PAD_CTL_DSE_50ohm | PAD_CTL_OBE_IBE_ENABLE)
 
+#define USB_PEN_GPIO83
+
+static const iomux_v3_cfg_t usb_pads[] = {
+	VF610_PAD_PTD4__GPIO_83,
+};
+
 int dram_init(void)
 {
 	static const struct ddr3_jedec_timings timings = {
@@ -503,3 +510,20 @@ int ft_board_setup(void *blob, bd_t *bd)
 	return fsl_dcu_fixedfb_setup(blob);
 }
 #endif
+
+#ifdef CONFIG_USB_EHCI_VF
+int board_ehci_hcd_init(int port)
+{
+	imx_iomux_v3_setup_multiple_pads(usb_pads, ARRAY_SIZE(usb_pads));
+
+	/*
+	 * USB0 is used as USB Client and USB1 is used
+	 * as USB host on Colibri Vybrid Modules.
+	 */
+
+	if (port)
+		gpio_direction_output(USB_PEN_GPIO, 0);
+
+	return 0;
+}
+#endif
diff --git a/drivers/usb/host/ehci-vf.c b/drivers/usb/host/ehci-vf.c
index 4aa3b9c..6fc9016 100644
--- a/drivers/usb/host/ehci-vf.c
+++ b/drivers/usb/host/ehci-vf.c
@@ -161,6 +161,11 @@ static void usb_oc_config(int index)
 	__raw_writel(val, ctrl);
 }
 
+int __weak board_ehci_hcd_init(int port)
+{
+	return 0;
+}
+
 int ehci_hcd_init(int index, enum usb_init_type init,
 		struct ehci_hccr **hccr, struct ehci_hcor **hcor)
 {
@@ -176,6 +181,9 @@ int ehci_hcd_init(int index, enum usb_init_type init,
 
 	ehci = (struct usb_ehci *)nc_reg_bases[index];
 
+	/* Do board specific initialisation */
+	board_echi_hcd_init(index);
+
 	usb_power_config(index);
 	usb_oc_config(index);
 	usb_internal_phy_clock_gate(index);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/7] Add support for Colibri Vybrid Modules

[maitysanchayan]

Hello,

On 15-04-15 16:24:21, Sanchayan Maity wrote:
 Hello,
 
 This is the third version of the patchset which adds support for the
 Toradex Colibri Vybrid VF50 and VF61 modules. Boot up has been tested
 using the serial loader over UART. Compile tested for vf610twr_defconfig
 and vf610twr_nand_defconfig as well. 
 
 First patch in the series refactors the DDR related code for use by both
 the tower board and colibri modules. It also introduces a DDR3 based
 JEDEC timing structure.
 
 Second third and fourth patch in this series are improvement patches
 related to RTC, SoC/CPU detection and caches.
 
 Fifth patch introduces USB support for Vybrid modules. Much of the code
 is similar to the ehci-mx6 driver. Both host and client modes are working
 and DFU has also been tested with client. Currently, we restrict the 
 ports to be in one of host and client mode.
 
 Sixth patch adds the actual support for the Colibri modules.
 
 Comments and feedback are most welcome. Thanks for the feedback till 
 now.
 
 The patchset is based and tested on the latest master branch as of
 this writing.
 
 Discussion on the version 2 of the patchset can be found at the below
 link:
 https://www.mail-archive.com/u-boot@lists.denx.de/msg168727.html
 
 Discussion on the version 1 of the patchset can be found at the below
 link:
 https://www.mail-archive.com/u-boot@lists.denx.de/msg168136.html
 
 Changes since v2:
 - Rework the USB driver to use register + offset method in light of
 discussion which Fabio Estevam pointed out instead of the regular 
 struct{} method which v2 used. The discussion is at the below link:
 https://www.marc.info/?l=u-bootm=142609602127309w=2
 
 - Reorder the patchset, putting the USB support in the end and add an
 additional patch for adding USB support to Colibri modules. By chance
 if more discussions happen on the USB support, this allows picking up
 of atleast the first patches on which no issues have been reported so
 far.
 
 - The register definitions have been moved under arch/arm/include/asm/
 imx-common in the regs-usbphy.h file. This was agreed on after 
 discussion with Marek and some input from Peter Chen. Since it is not 
 clear if SoC's other than Freescale's use the Sigmatel Phy's which seem
 to be use in iMX/VF/MXS, put the USH PHY register definitions in 
 imx-common rather than include/usb in a chipidea specific file.
 
 - Remove setting of a PLL divisor select which was added for USB but is
 actually not required considering default value. It also seems to break 
 USB after my latest rebase. The file in question concerning the change 
 is colibri_vf.c. PLL divisor selects the PLL Multiplication factor which 
 by default is 0, setting Fout = Fref * 20 giving 480MHz. The earlier 
 patch set this to 1 giving Fout = Fref * 22 where Fref = 24MHz.
 
 - Rebased on the latest master branch.
 
 Changes since v1:
 - Rework the USB driver to use register offsets using the regular
 struct {} method
 
 - Some cleanups and fixes in the sixth patch for the colibri_vf.h file
 which takes care of environment variables in uboot
 
 - Purge some useless defines in the fifth and sixth patch which were
 related to USB.

Ping!?

Anything preventing this patch from getting applied?

- Sanchayan.

 
 - Sanchayan.
 
 Sanchayan Maity (5):
   ARM: vf610: Move DDR3 initialization to imx-common
   ARM: vf610: Add SoC and CPU type detection
   ARM: vf610: Initial integration for Colibri VF50/VF61
   usb: host: Add ehci-vf USB driver for ARM Vybrid SoC's
   colibri_vf: Enable USB support for Colibri Vybrid
 
 Stefan Agner (2):
   ARM: vf610: Enable external 32KHz oscillator
   ARM: vf610: Enable caches
 
  arch/arm/Kconfig  |   5 +
  arch/arm/cpu/armv7/vf610/generic.c|  45 ++-
  arch/arm/imx-common/Makefile  |   3 +
  arch/arm/imx-common/ddrmc-vf610.c | 278 +++
  arch/arm/include/asm/arch-vf610/crm_regs.h|  11 +
  arch/arm/include/asm/arch-vf610/ddrmc-vf610.h |  72 +
  arch/arm/include/asm/arch-vf610/imx-regs.h|  36 ++-
  arch/arm/include/asm/imx-common/regs-usbphy.h |  26 ++
  board/freescale/vf610twr/vf610twr.c   | 295 +---
  board/toradex/colibri_vf/Kconfig  |  18 ++
  board/toradex/colibri_vf/MAINTAINERS  |   6 +
  board/toradex/colibri_vf/Makefile |   7 +
  board/toradex/colibri_vf/colibri_vf.c | 382 
 ++
  board/toradex/colibri_vf/imximage.cfg |  17 ++
  configs/colibri_vf_defconfig  |   3 +
  drivers/usb/host/Makefile |   1 +
  drivers/usb/host/ehci-vf.c| 164 +++
  include/configs/colibri_vf.h  | 271 ++
  18 files changed, 1405 insertions(+), 235 deletions(-)
  create mode 100644 arch/arm/imx-common/ddrmc-vf610.c
  create mode 100644 arch/arm/include/asm/arch-vf610/ddrmc-vf610.h
  create mode 100644 

Re: [U-Boot] [PATCH v3 7/7] colibri_vf: Enable USB support for Colibri Vybrid

[maitysanchayan]

Hello,

On 15-04-16 22:21:11, Marek Vasut wrote:
 On Wednesday, April 15, 2015 at 12:54:28 PM, Sanchayan Maity wrote:
  Enable USB support on Toradex Colibri Vybrid Modules.
  
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
   board/toradex/colibri_vf/colibri_vf.c | 25 +--
   include/configs/colibri_vf.h  | 37
  +++ 2 files changed, 60 insertions(+), 2
  deletions(-)
  
  diff --git a/board/toradex/colibri_vf/colibri_vf.c
  b/board/toradex/colibri_vf/colibri_vf.c index e7bc6c1..054e6f9 100644
  --- a/board/toradex/colibri_vf/colibri_vf.c
  +++ b/board/toradex/colibri_vf/colibri_vf.c
  @@ -197,7 +197,8 @@ static void clock_init(void)
  clrsetbits_le32(ccm-ccgr0, CCM_REG_CTRL_MASK,
  CCM_CCGR0_UART0_CTRL_MASK);
  clrsetbits_le32(ccm-ccgr1, CCM_REG_CTRL_MASK,
  -   CCM_CCGR1_PIT_CTRL_MASK | CCM_CCGR1_WDOGA5_CTRL_MASK);
  +   CCM_CCGR1_PIT_CTRL_MASK | CCM_CCGR1_WDOGA5_CTRL_MASK |
  +   CCM_CCGR1_USBC0_CTRL_MASK);
 
 You probably want to flip these CCM regs only if CONFIG_CI_UDC is enabled
 or something along those lines, right ?

Yes, that would be be better. Will send a new corrected patch for this. 
I assume since there are no issues with the rest of the patchset so 
sending a respin of this last patch would do?!

Thanks for the feedback and catching this.

 
 Best regards,
 Marek Vasut

- Sanchayan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/6] Add support for Colibri Vybrid Modules

[maitysanchayan]

Hello,

On 15-04-14 09:06:27, Peter Chen wrote:
 
  
   
Hi!
   
Stefano, maybe you can pick 1,2,3,4,6 right away for next?
This way, we can solve 5/6 separately, since it might need
some further dicussion. I don't want that patch to block the
rest of the series though.
  
   The sixth patch has some minor dependencies on the fifth patch
   like some #defines and configuration we enable for Colibri. In
   case the fifth patch will require some more discussion and
   time, then I guess I will need to rework the sixth patch and
   then everything related to USB can go in a later patch. The
   rework will be minor. So the v3 will be without USB support
 
  Well, if you want to rework the 6th patch, that'd be very nice
  of you :)

 Yes sure. Will put the USB support in the end or not, the first
 patches can go in atleast since there seem to be no complaints on
 them so far.

   and USB will go in later once this gets applied. Perhaps we
   will send the USB along with some more other featureset
   addition like gpio support for Vybrid which my colleague did
   recently along with some driver model/dt stuff.
 
  My impression is that the USB is just a matter of figuring out
  where the PHY registers go -- whether in
  arch/arm/include/imx-common or into include/usb/ . I'd be more
  inclined for the later, since the PHY regs looks like chipidea IP 
  specific
  thing, but I might be wrong.

 I would say it looks like chipidea specific but I have not looked
 at IPs other than Freescale controllers to be sure.
   
I think it's CI-specific indeed, thus include/usb/ . +CC Peter, who
might chime in whether the PHY is CI-specific or IMX-specific.
  
   Which PHY? Vybrid? In Linux kernel, it belongs to mxs PHY.
   The same controller can integrate different PHYs.
  
  Yeah. Is the PHY MXS/IMX/VF specific or can that PHY be found even on other
  SoCs not manufactured by Freescale ?
  
  
 This mxs PHY is from SigmaTel, I only see this PHY is used at FSL SoCs, but 
 not sure
 if others use it.

So Chipidea IP with the SigmaTel phy. It might be better to have the 
regs-usbphy.h viz. register phy definitions in imx-common then since it 
is not clear if SoC's other than Freescale's use the same phy.

Marek, what do you think?

- Sanchayan.


 Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/6] Add support for Colibri Vybrid Modules

[maitysanchayan]

Hello,

On 15-04-13 01:28:07, Marek Vasut wrote:
 On Sunday, April 12, 2015 at 07:33:41 AM, maitysancha...@gmail.com wrote:
  Hi,
  
  On 15-04-11 18:46:15, Marek Vasut wrote:
   On Wednesday, April 08, 2015 at 03:20:04 PM, Sanchayan Maity wrote:
Hello,

This is the second version of the patchset which adds support for the
Toradex Colibri Vybrid VF50 and VF61 modules. Boot up has been tested
using the serial loader over UART.
   
   Hi!
   
   Stefano, maybe you can pick 1,2,3,4,6 right away for next? This way, we
   can solve 5/6 separately, since it might need some further dicussion. I
   don't want that patch to block the rest of the series though.
  
  The sixth patch has some minor dependencies on the fifth patch like some
  #defines and configuration we enable for Colibri. In case the fifth
  patch will require some more discussion and time, then I guess I will
  need to rework the sixth patch and then everything related to USB can
  go in a later patch. The rework will be minor. So the v3 will be without
  USB support
 
 Well, if you want to rework the 6th patch, that'd be very nice of you :)

Yes sure. Will put the USB support in the end or not, the first patches 
can go in atleast since there seem to be no complaints on them so far.

 
  and USB will go in later once this gets applied. Perhaps we
  will send the USB along with some more other featureset addition like
  gpio support for Vybrid which my colleague did recently along with some
  driver model/dt stuff.
 
 My impression is that the USB is just a matter of figuring out where the
 PHY registers go -- whether in arch/arm/include/imx-common or into
 include/usb/ . I'd be more inclined for the later, since the PHY regs
 looks like chipidea IP specific thing, but I might be wrong.

I would say it looks like chipidea specific but I have not looked at IPs 
other than Freescale controllers to be sure.

 
  By the way, where the fifth patch is concerned, is it related to the
  discussion Fabio pointed out in the discussion on first version of the
  patch? uboot trying to get rid of the 'no register access via offset'
  rule? Anything required I can rework accordingly.
 
 I was concerned about the placement of the PHY reg definition. I didn't
 hear from Fabio on the result of this decision and I don't really mind
 that either way.

Ok. So I assume the driver can resort to the way it was in the first 
version while being changed with regards to three points 1. Use of 
clrsetbits_ related functions 2. Register phy definitions going in 
either of imx-common/ or include/usb/ with chipidea name. 3. No need to 
use offset accesses with the struct{} in light of the discussion Fabio 
pointed out.

 
 Best regards,
 Marek Vasut

Thanks  Regards,
Sanchayan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 5/6] usb: host: Add ehci-vf USB driver for ARM Vybrid SoC's

[maitysanchayan]

Hello,

On 15-04-13 01:29:39, Marek Vasut wrote:
 On Wednesday, April 08, 2015 at 03:20:09 PM, Sanchayan Maity wrote:
  This driver adds support for the USB peripheral on Freescale Vybrid
  SoC's.
  
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
   arch/arm/include/asm/arch-vf610/crm_regs.h|  10 ++
   arch/arm/include/asm/arch-vf610/imx-regs.h|   4 +
   arch/arm/include/asm/arch-vf610/regs-usbphy.h |  31 
   drivers/usb/host/Makefile |   1 +
   drivers/usb/host/ehci-vf.c| 196
  ++ 5 files changed, 242 insertions(+)
   create mode 100644 arch/arm/include/asm/arch-vf610/regs-usbphy.h
   create mode 100644 drivers/usb/host/ehci-vf.c
 
 A general hint, you can replace sequences of code like this:
 
 var = readl(foo);
 var |= BIT_BAR;
 writel(var, addr);
 
 with
 
 setbits_le32(var, BIT_BAR);
 
 Same applies for clearing -- clrbits_le32() and both setting and
 clearing -- clrsetbits_le32().

Sorry about that. It is something which I use in the sixth patch 
as well in the board files but it skipped my mind while doing this 
driver. Will take care of it in v3 which seems imminent.

Noted, thanks :).

- Sanchayan.

 
 Thanks!
 
 Best regards,
 Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/6] Add support for Colibri Vybrid Modules

[maitysanchayan]

Hi,

On 15-04-11 18:46:15, Marek Vasut wrote:
 On Wednesday, April 08, 2015 at 03:20:04 PM, Sanchayan Maity wrote:
  Hello,
  
  This is the second version of the patchset which adds support for the
  Toradex Colibri Vybrid VF50 and VF61 modules. Boot up has been tested
  using the serial loader over UART.
 
 Hi!
 
 Stefano, maybe you can pick 1,2,3,4,6 right away for next? This way, we
 can solve 5/6 separately, since it might need some further dicussion. I
 don't want that patch to block the rest of the series though.

The sixth patch has some minor dependencies on the fifth patch like some 
#defines and configuration we enable for Colibri. In case the fifth 
patch will require some more discussion and time, then I guess I will 
need to rework the sixth patch and then everything related to USB can 
go in a later patch. The rework will be minor. So the v3 will be without 
USB support and USB will go in later once this gets applied. Perhaps we
will send the USB along with some more other featureset addition like
gpio support for Vybrid which my colleague did recently along with some
driver model/dt stuff.

By the way, where the fifth patch is concerned, is it related to the 
discussion Fabio pointed out in the discussion on first version of the 
patch? uboot trying to get rid of the 'no register access via offset' 
rule? Anything required I can rework accordingly.

Thanks  Regards,
Sanchayan Maity.

 
 Best regards,
 Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RESEND PATCH 5/6] usb: host: Add ehci-vf USB driver for ARM Vybrid SoC's

[maitysanchayan]

Hello,

On 15-04-09 18:09:46, Marek Vasut wrote:
 On Tuesday, April 07, 2015 at 09:03:45 AM, maitysancha...@gmail.com wrote:
  Hello,
  
  On 15-04-01 21:15:21, Marek Vasut wrote:
   On Wednesday, April 01, 2015 at 11:54:22 AM, Sanchayan Maity wrote:
   
   The commit message is missing, please fix in v2.
   
Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
   
   [...]
   
+#define USB_NC_REG_OFFSET  0x0800
+#define USBCx_CTRL_OFFSET  0x
+#define USBCx_PHY_CTRL_OFFSET  0x0018
   
   Please define the register offsets using the regular struct {} method,
   see for example struct mxs_usbphy_regs and it's usage in ehci-mxs.c .
  
  I had a query here, just to be sure and avoid rework. The vybrid defines
  would be similar to mxs. I assume I can add them to the regs-common.h
  file along with a note that the VF610 also has the same _set, _clr,
  _tog register? Or perhaps it would be more appropriate to have the file
  have generic names which mxs, vf and imx can all leverage? Though for
  now this would require reworking all the three drivers.
  
  The USB phy definitions part is ok, as they would go in the arch
  specific folder.
 
 If these are really IMX/MXS/VF specific, then the defines should go into
 arch/arm/include/asm/imx-common/ . Otherwise, you can make chipidea specific 
 file in include/usb/ .

Not really much VF specific. I was not sure about using the mxs_ prefix 
accessors for VF as well. In the end I found usage in one iMX6 file and 
decided that it makes better sense to actually use the mxs_ existing 
defines. They can be used for Vybrid as well. Except for the non core 
regsiters and a few others no other difference.

I send a v2 version of the patchset based taking your suggestion into 
account. The driver looks cleaner in comparison to the previous :) 
IMHO. Thanks.

https://www.mail-archive.com/u-boot@lists.denx.de/msg168727.html


- Sanchayan.

 
+#define USBPHY_CTRL
 0x0030
+#define USBPHY_CTRL_SET
0x0034
+#define USBPHY_CTRL_CLR
0x0038
+#define USBPHY_CTRL_TOG
0x003c
+
+#define USBPHY_PWD 
 0x
+#define USBPHY_TX  
 0x0010
+#define USBPHY_RX  
 0x0020
+#define USBPHY_DEBUG   0x0050
+#define USBPHY_CTRL_SFTRST 0x8000
+#define USBPHY_CTRL_CLKGATE0x4000
+#define USBPHY_CTRL_ENUTMILEVEL3   0x8000
+#define USBPHY_CTRL_ENUTMILEVEL2   0x4000
+#define USBPHY_CTRL_OTG_ID 0x0800
+
+#define ANADIG_PLL_CTRL_BYPASS 0x0001
+#define ANADIG_PLL_CTRL_ENABLE 0x2000
+#define ANADIG_PLL_CTRL_POWER  0x1000
+#define ANADIG_PLL_CTRL_EN_USB_CLKS0x0040
+
+#define UCTRL_OVER_CUR_POL (1  8) /* OTG Polarity of Overcurrent 
 */
+#define UCTRL_OVER_CUR_DIS (1  7) /* Disable OTG Overcurrent
Detection */ +
+/* USBCMD */
+#define UCMD_RUN_STOP  (1  0) /* controller run/stop */
+#define UCMD_RESET (1  1) /* controller reset */
   
   This looks very much like the USB PHY used on MX28 , can you double-check
   this please ?
  
  MX28 IP also seems similar to the Vybrid USB IP except for a few
  registers and the non core registers. Perhaps to be expected as they all
  have a common chipidea IP core, though having a different version
  thereof.
 
 Yep, I agree :)
 
 Thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RESEND PATCH 5/6] usb: host: Add ehci-vf USB driver for ARM Vybrid SoC's

[maitysanchayan]

Hello,

On 15-04-01 21:15:21, Marek Vasut wrote:
 On Wednesday, April 01, 2015 at 11:54:22 AM, Sanchayan Maity wrote:
 
 The commit message is missing, please fix in v2.
 
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
 
 [...]
 
  +#define USB_NC_REG_OFFSET  0x0800
  +#define USBCx_CTRL_OFFSET  0x
  +#define USBCx_PHY_CTRL_OFFSET  0x0018
 
 Please define the register offsets using the regular struct {} method,
 see for example struct mxs_usbphy_regs and it's usage in ehci-mxs.c .

I had a query here, just to be sure and avoid rework. The vybrid defines 
would be similar to mxs. I assume I can add them to the regs-common.h 
file along with a note that the VF610 also has the same _set, _clr, 
_tog register? Or perhaps it would be more appropriate to have the file 
have generic names which mxs, vf and imx can all leverage? Though for 
now this would require reworking all the three drivers.

The USB phy definitions part is ok, as they would go in the arch 
specific folder.

Thoughts?

 
  +#define USBPHY_CTRL
  0x0030
  +#define USBPHY_CTRL_SET0x0034
  +#define USBPHY_CTRL_CLR0x0038
  +#define USBPHY_CTRL_TOG0x003c
  +
  +#define USBPHY_PWD 0x
  +#define USBPHY_TX  0x0010
  +#define USBPHY_RX  0x0020
  +#define USBPHY_DEBUG   0x0050
  +#define USBPHY_CTRL_SFTRST 0x8000
  +#define USBPHY_CTRL_CLKGATE0x4000
  +#define USBPHY_CTRL_ENUTMILEVEL3   0x8000
  +#define USBPHY_CTRL_ENUTMILEVEL2   0x4000
  +#define USBPHY_CTRL_OTG_ID 0x0800
  +
  +#define ANADIG_PLL_CTRL_BYPASS 0x0001
  +#define ANADIG_PLL_CTRL_ENABLE 0x2000
  +#define ANADIG_PLL_CTRL_POWER  0x1000
  +#define ANADIG_PLL_CTRL_EN_USB_CLKS0x0040
  +
  +#define UCTRL_OVER_CUR_POL (1  8) /* OTG Polarity of Overcurrent */
  +#define UCTRL_OVER_CUR_DIS (1  7) /* Disable OTG Overcurrent Detection
  */ +
  +/* USBCMD */
  +#define UCMD_RUN_STOP  (1  0) /* controller run/stop */
  +#define UCMD_RESET (1  1) /* controller reset */
 
 This looks very much like the USB PHY used on MX28 , can you double-check this
 please ?

MX28 IP also seems similar to the Vybrid USB IP except for a few 
registers and the non core registers. Perhaps to be expected as they all 
have a common chipidea IP core, though having a different version 
thereof.

 
 Best regards,
 Marek Vasut

- Sanchayan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RESEND PATCH 0/6] Add support for Colibri Vybrid Modules

[maitysanchayan]

Hello Tom,

On 15-04-01 07:27:07, Tom Rini wrote:
 On Wed, Apr 01, 2015 at 03:24:17PM +0530, Sanchayan Maity wrote:
 
  Hello,
  
  This patchset adds support for the Toradex Colibri Vybrid VF50 and VF61
  modules. Boot up has been tested using the serial loader over UART.
  
  First patch in the series refactors the DDR related code for use by both
  the tower board and colibri modules. It also introduces a DDR3 based
  JEDEC timing structure.
  
  Second third and fourth patch in this series are improvement patches
  related to RTC, SoC/CPU detection and caches.
  
  Fifth patch introduces USB support for Vybrid modules. Much of the code
  is similar to the ehci-mx6 driver. One open question here would be is
  there a better way to take care of this similarity and perhaps share the
  code base among the two drivers? Both host and client modes are working
  and DFU has also been tested. Currently, we restrict the ports to be in
  one of host and client mode.
  
  Sixth patch adds the actual support for the Colibri modules.
  
  Comments and feedback are most welcome.
 
 Aside from the minor comments, I'll take this after the release, thanks!

Sure, works for me. We were thinking of posting this patchset after the 
current release, but, decided against it. Hopefully till then this 
should accumulate enough feedback and I will send the improved v2 then.

Thanks.

 
 -- 
 Tom

- Sanchayan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RESEND PATCH 5/6] usb: host: Add ehci-vf USB driver for ARM Vybrid SoC's

[maitysanchayan]

Hello,

On 15-04-01 21:15:21, Marek Vasut wrote:
 On Wednesday, April 01, 2015 at 11:54:22 AM, Sanchayan Maity wrote:
 
 The commit message is missing, please fix in v2.

Ok. Will add the commit message in v2.

 
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
 
 [...]
 
  +#define USB_NC_REG_OFFSET  0x0800
  +#define USBCx_CTRL_OFFSET  0x
  +#define USBCx_PHY_CTRL_OFFSET  0x0018
 
 Please define the register offsets using the regular struct {} method,
 see for example struct mxs_usbphy_regs and it's usage in ehci-mxs.c .

Ok. Will fix in v2.

 
  +#define USBPHY_CTRL
  0x0030
  +#define USBPHY_CTRL_SET0x0034
  +#define USBPHY_CTRL_CLR0x0038
  +#define USBPHY_CTRL_TOG0x003c
  +
  +#define USBPHY_PWD 0x
  +#define USBPHY_TX  0x0010
  +#define USBPHY_RX  0x0020
  +#define USBPHY_DEBUG   0x0050
  +#define USBPHY_CTRL_SFTRST 0x8000
  +#define USBPHY_CTRL_CLKGATE0x4000
  +#define USBPHY_CTRL_ENUTMILEVEL3   0x8000
  +#define USBPHY_CTRL_ENUTMILEVEL2   0x4000
  +#define USBPHY_CTRL_OTG_ID 0x0800
  +
  +#define ANADIG_PLL_CTRL_BYPASS 0x0001
  +#define ANADIG_PLL_CTRL_ENABLE 0x2000
  +#define ANADIG_PLL_CTRL_POWER  0x1000
  +#define ANADIG_PLL_CTRL_EN_USB_CLKS0x0040
  +
  +#define UCTRL_OVER_CUR_POL (1  8) /* OTG Polarity of Overcurrent */
  +#define UCTRL_OVER_CUR_DIS (1  7) /* Disable OTG Overcurrent Detection
  */ +
  +/* USBCMD */
  +#define UCMD_RUN_STOP  (1  0) /* controller run/stop */
  +#define UCMD_RESET (1  1) /* controller reset */
 
 This looks very much like the USB PHY used on MX28 , can you double-check this
 please ?

I have not yet looked at MX28, but, the Vybrid USB IP is in fact very 
similar to i.MX6, however, the non core registers are spread in two 
different register areas. Will have a look at MX28 as well.

This ehci-vf driver is very closely based on ehci-mx6 driver already in 
uboot. 

 
 Best regards,
 Marek Vasut

- Sanchayan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot