[U-Boot] [PATCH] MIPS: add atomic operations support.
some of the u-boot frameworks like ubi-fs and eth_gadget
uses atomic_* api's. So add atomic api's for mips.
This makes ubi-fs on nand work with mips platform.
Signed-off-by: Govindraj Raja govindraj.r...@imgtec.com
---
arch/mips/include/asm/atomic.h | 90 ++
1 file changed, 90 insertions(+)
create mode 100644 arch/mips/include/asm/atomic.h
diff --git a/arch/mips/include/asm/atomic.h b/arch/mips/include/asm/atomic.h
new file mode 100644
index 000..163e7e2
--- /dev/null
+++ b/arch/mips/include/asm/atomic.h
@@ -0,0 +1,90 @@
+/*
+ * Based on: linux/arch/mips/include/asm/atomic.h
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __ASM_MIPS_ATOMIC_H
+#define __ASM_MIPS_ATOMIC_H
+
+typedef struct { volatile int counter; } atomic_t;
+
+#define ATOMIC_INIT(i) { (i) }
+
+#include asm/system.h
+
+#define atomic_read(v) ((v)-counter)
+#define atomic_set(v, i) (((v)-counter) = (i))
+
+static inline void atomic_add(int i, volatile atomic_t *v)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+ v-counter += i;
+ local_irq_restore(flags);
+}
+
+static inline void atomic_sub(int i, volatile atomic_t *v)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+ v-counter -= i;
+ local_irq_restore(flags);
+}
+
+static inline void atomic_inc(volatile atomic_t *v)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+ v-counter += 1;
+ local_irq_restore(flags);
+}
+
+static inline void atomic_dec(volatile atomic_t *v)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+ v-counter -= 1;
+ local_irq_restore(flags);
+}
+
+static inline int atomic_dec_and_test(volatile atomic_t *v)
+{
+ unsigned long flags;
+ int val;
+
+ local_irq_save(flags);
+ val = v-counter;
+ v-counter = val -= 1;
+ local_irq_restore(flags);
+
+ return val == 0;
+}
+
+static inline int atomic_add_negative(int i, volatile atomic_t *v)
+{
+ unsigned long flags;
+ int val;
+
+ local_irq_save(flags);
+ val = v-counter;
+ v-counter = val += i;
+ local_irq_restore(flags);
+
+ return val 0;
+}
+
+static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+ *addr = ~mask;
+ local_irq_restore(flags);
+}
+
+#endif /* __ASM_MIPS_ATOMIC_H */
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] MIPS: add clrbits and setbits and add phy_to_bus support.
-Original Message- From: Daniel Schwierzeck [mailto:daniel.schwierz...@gmail.com] Sent: 21 August 2015 02:21 PM To: Govindraj Raja Cc: u-boot@lists.denx.de Subject: Re: [U-Boot][PATCH v2 1/2] MIPS: add clrbits and setbits and add phy_to_bus support. Am 20.08.2015 um 16:01 schrieb Govindraj Raja: From: Govindraj Raja govindraj.r...@imgtec.com usb stack utilizes the clr/set_bits macros also usb stack needs phy_to_bus/bus_to_phys functions. Thus adding these macro and functions for mips platform. This makes usb stack usable with mips platform. Signed-off-by: Govindraj Raja govindraj.r...@imgtec.com --- Changes from v1: --- Fixes comments from Daniel as dicussed in below thread: https://patchwork.ozlabs.org/patch/508821/ arch/mips/include/asm/io.h | 54 ++ arch/mips/lib/io.c | 14 2 files changed, 68 insertions(+) applied to u-boot-mips/next, thanks thanks the following include files were missing in io.c +#include asm/io.h +#include linux/compiler.h Sorry I missed it. -- Thanks, Govindraj.R ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] MIPS: add clrbits and setbits and add phy_to_bus support.
From: Govindraj Raja govindraj.r...@imgtec.com
usb stack utilizes the clr/set_bits macros
also usb stack needs phy_to_bus/bus_to_phys functions.
Thus adding these macro and functions for mips platform.
This makes usb stack usable with mips platform.
Signed-off-by: Govindraj Raja govindraj.r...@imgtec.com
---
Changes from v1:
---
Fixes comments from Daniel as dicussed in below thread:
https://patchwork.ozlabs.org/patch/508821/
arch/mips/include/asm/io.h | 54 ++
arch/mips/lib/io.c | 14
2 files changed, 68 insertions(+)
diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
index a7ab087..4093941 100644
--- a/arch/mips/include/asm/io.h
+++ b/arch/mips/include/asm/io.h
@@ -504,4 +504,58 @@ static inline void unmap_physmem(void *vaddr, unsigned
long flags)
}
+#define out_arch(type, endian, a, v) __raw_write##type(cpu_to_##endian(v), a)
+#define in_arch(type, endian, a) endian##_to_cpu(__raw_read##type(a))
+
+#define out_le32(a, v) out_arch(l, le32, a, v)
+#define out_le16(a, v) out_arch(w, le16, a, v)
+
+#define in_le32(a) in_arch(l, le32, a)
+#define in_le16(a) in_arch(w, le16, a)
+
+#define out_be32(a, v) out_arch(l, be32, a, v)
+#define out_be16(a, v) out_arch(w, be16, a, v)
+
+#define in_be32(a) in_arch(l, be32, a)
+#define in_be16(a) in_arch(w, be16, a)
+
+#define out_8(a, v)__raw_writeb(v, a)
+#define in_8(a)__raw_readb(a)
+
+/*
+ * Clear and set bits in one shot. These macros can be used to clear and
+ * set multiple bits in a register using a single call. These macros can
+ * also be used to set a multiple-bit bit pattern using a mask, by
+ * specifying the mask in the 'clear' parameter and the new bit pattern
+ * in the 'set' parameter.
+ */
+
+#define clrbits(type, addr, clear) \
+ out_##type((addr), in_##type(addr) ~(clear))
+
+#define setbits(type, addr, set) \
+ out_##type((addr), in_##type(addr) | (set))
+
+#define clrsetbits(type, addr, clear, set) \
+ out_##type((addr), (in_##type(addr) ~(clear)) | (set))
+
+#define clrbits_be32(addr, clear) clrbits(be32, addr, clear)
+#define setbits_be32(addr, set) setbits(be32, addr, set)
+#define clrsetbits_be32(addr, clear, set) clrsetbits(be32, addr, clear, set)
+
+#define clrbits_le32(addr, clear) clrbits(le32, addr, clear)
+#define setbits_le32(addr, set) setbits(le32, addr, set)
+#define clrsetbits_le32(addr, clear, set) clrsetbits(le32, addr, clear, set)
+
+#define clrbits_be16(addr, clear) clrbits(be16, addr, clear)
+#define setbits_be16(addr, set) setbits(be16, addr, set)
+#define clrsetbits_be16(addr, clear, set) clrsetbits(be16, addr, clear, set)
+
+#define clrbits_le16(addr, clear) clrbits(le16, addr, clear)
+#define setbits_le16(addr, set) setbits(le16, addr, set)
+#define clrsetbits_le16(addr, clear, set) clrsetbits(le16, addr, clear, set)
+
+#define clrbits_8(addr, clear) clrbits(8, addr, clear)
+#define setbits_8(addr, set) setbits(8, addr, set)
+
#endif /* _ASM_IO_H */
diff --git a/arch/mips/lib/io.c b/arch/mips/lib/io.c
index b2d4a09..58a66fc 100644
--- a/arch/mips/lib/io.c
+++ b/arch/mips/lib/io.c
@@ -10,3 +10,17 @@
* I/O ports are mapped.
*/
const unsigned long mips_io_port_base = -1;
+
+#ifdef CONFIG_PHYS_TO_BUS
+
+__weak unsigned long phys_to_bus(unsigned long phys)
+{
+ return (unsigned long)virt_to_phys((void *)phys);
+}
+
+__weak unsigned long bus_to_phys(unsigned long bus)
+{
+ return (unsigned long)phys_to_virt(bus);
+}
+
+#endif
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] MIPS: fix syntax for fdt_chosen/initrd.
From: Govindraj Raja govindraj.r...@imgtec.com The syntax for the fdt_chosen/initrd functions seem to deprecated in usage from MIPS bootm implementation. Third parameter is no more used in these api's Refer to : include/fdt_support.h Signed-off-by: Govindraj Raja govindraj.r...@imgtec.com --- arch/mips/lib/bootm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c index e289799..9c647aa 100644 --- a/arch/mips/lib/bootm.c +++ b/arch/mips/lib/bootm.c @@ -95,10 +95,10 @@ static void boot_setup_fdt(bootm_headers_t *images) debug(## setup FDT\n); - fdt_chosen(images-ft_addr, 1); + fdt_chosen(images-ft_addr); fdt_fixup_memory_banks(images-ft_addr, mem_start, mem_size, 1); fdt_fixup_ethernet(images-ft_addr); - fdt_initrd(images-ft_addr, images-initrd_start, images-initrd_end, 1); + fdt_initrd(images-ft_addr, images-initrd_start, images-initrd_end); #if defined(CONFIG_OF_BOARD_SETUP) ft_board_setup(images-ft_addr, gd-bd); -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] MIPS: add clrbits and setbits and add phy_to_bus support.
From: Govindraj Raja govindraj.r...@imgtec.com
usb stack utilizes the clr/set_bits macros
also usb stack needs phy_to_bus/bus_to_phys functions.
Thus adding these macro and functions for mips platform.
This makes usb stack usable with mips platform.
Also fixes a checkpatch warning with virt_to_phys
forward declaration.
Signed-off-by: Govindraj Raja govindraj.r...@imgtec.com
---
arch/mips/include/asm/io.h | 71 +-
1 file changed, 70 insertions(+), 1 deletion(-)
diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
index a7ab087..8dc521c 100644
--- a/arch/mips/include/asm/io.h
+++ b/arch/mips/include/asm/io.h
@@ -117,7 +117,7 @@ static inline void set_io_port_base(unsigned long base)
* Change virtual addresses to physical addresses and vv.
* These are trivial on the 1:1 Linux/MIPS mapping
*/
-static inline phys_addr_t virt_to_phys(volatile void * address)
+static inline phys_addr_t virt_to_phys(volatile void *address)
{
#ifndef CONFIG_64BIT
return CPHYSADDR(address);
@@ -504,4 +504,73 @@ static inline void unmap_physmem(void *vaddr, unsigned
long flags)
}
+#define out_arch(type, endian, a, v) __raw_write##type(cpu_to_##endian(v), a)
+#define in_arch(type, endian, a) endian##_to_cpu(__raw_read##type(a))
+
+#define out_le32(a, v) out_arch(l, le32, a, v)
+#define out_le16(a, v) out_arch(w, le16, a, v)
+
+#define in_le32(a) in_arch(l, le32, a)
+#define in_le16(a) in_arch(w, le16, a)
+
+#define out_be32(a, v) out_arch(l, be32, a, v)
+#define out_be16(a, v) out_arch(w, be16, a, v)
+
+#define in_be32(a) in_arch(l, be32, a)
+#define in_be16(a) in_arch(w, be16, a)
+
+#define out_8(a, v)__raw_writeb(v, a)
+#define in_8(a)__raw_readb(a)
+
+/*
+ * Clear and set bits in one shot. These macros can be used to clear and
+ * set multiple bits in a register using a single call. These macros can
+ * also be used to set a multiple-bit bit pattern using a mask, by
+ * specifying the mask in the 'clear' parameter and the new bit pattern
+ * in the 'set' parameter.
+ */
+
+#define clrbits(type, addr, clear) \
+ out_##type((addr), in_##type(addr) ~(clear))
+
+#define setbits(type, addr, set) \
+ out_##type((addr), in_##type(addr) | (set))
+
+#define clrsetbits(type, addr, clear, set) \
+ out_##type((addr), (in_##type(addr) ~(clear)) | (set))
+
+#define clrbits_be32(addr, clear) clrbits(be32, addr, clear)
+#define setbits_be32(addr, set) setbits(be32, addr, set)
+#define clrsetbits_be32(addr, clear, set) clrsetbits(be32, addr, clear, set)
+
+#define clrbits_le32(addr, clear) clrbits(le32, addr, clear)
+#define setbits_le32(addr, set) setbits(le32, addr, set)
+#define clrsetbits_le32(addr, clear, set) clrsetbits(le32, addr, clear, set)
+
+#define clrbits_be16(addr, clear) clrbits(be16, addr, clear)
+#define setbits_be16(addr, set) setbits(be16, addr, set)
+#define clrsetbits_be16(addr, clear, set) clrsetbits(be16, addr, clear, set)
+
+#define clrbits_le16(addr, clear) clrbits(le16, addr, clear)
+#define setbits_le16(addr, set) setbits(le16, addr, set)
+#define clrsetbits_le16(addr, clear, set) clrsetbits(le16, addr, clear, set)
+
+#define clrbits_8(addr, clear) clrbits(8, addr, clear)
+#define setbits_8(addr, set) setbits(8, addr, set)
+
+#ifdef CONFIG_PHYS_TO_BUS
+
+extern inline unsigned long phys_to_bus(unsigned long phys)
+{
+ return (unsigned long)virt_to_phys((void *)phys);
+}
+
+extern inline unsigned long bus_to_phys(unsigned long bus)
+{
+ return (unsigned long)phys_to_virt(bus);
+}
+
+#endif
+
+
#endif /* _ASM_IO_H */
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] MIPS: add support to support usb stack for mips and minor cleanup
Patch prepares to support usb stack compiled for mips platform. Also fix fdt usage api's from bootm. Govindraj Raja (2): MIPS: add clrbits and setbits and add phy_to_bus support. MIPS: fix syntax for fdt_chosen/initrd. arch/mips/include/asm/io.h | 71 +- arch/mips/lib/bootm.c | 4 +-- 2 files changed, 72 insertions(+), 3 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ehci-omap: fix for enabling the correct usb port
On Fri, Apr 20, 2012 at 2:55 AM, Jeroen Hofstee jer...@myspectrum.nl wrote:
This is just a patch for the problem reported here:
http://lists.denx.de/pipermail/u-boot/2012-February/117580.html originally
reported by Igor.
Looks like this is copy paste error from my side,(for port2/3 it should have
been bypass
for port2/3 rather its port1 set in bypass mode)
I only submit the patch since it is missing in 2012.04-rc3 while the twister
board
depends on it. Maybe it is already somewhere in the reposistory, but I cannot
find it.
note: the twister boards still needs an additional `usb reset`, don't know
why.
U-Boot 2012.04-rc3-dirty (Apr 19 2012 - 21:38:38)
AM35XX-GP ES1.0, CPU-OPP2, L3-165MHz, Max CPU Clock 600 Mhz
TAM3517 TWISTER Board + LPDDR/NAND
I2C: ready
DRAM: 256 MiB
NAND: 512 MiB
MMC: OMAP SD/MMC: 0
In: serial
Out: serial
Err: serial
Die ID #746c0155dc1405011024
Net: DaVinci-EMAC, smc911x-0
Hit any key to stop autoboot: 0
twister = usb start
(Re)start USB...
USB: Register 1313 NbrPorts 3
USB EHCI 1.00
scanning bus for devices... 1 USB Device(s) found
scanning bus for storage devices... 0 Storage Device(s) found
twister = usb reset
(Re)start USB...
USB: Register 1313 NbrPorts 3
USB EHCI 1.00
scanning bus for devices... 1 USB Device(s) found
scanning bus for storage devices... 0 Storage Device(s) found
twister = usb reset
(Re)start USB...
USB: Register 1313 NbrPorts 3
USB EHCI 1.00
scanning bus for devices... 1 USB Device(s) found
scanning bus for storage devices... 0 Storage Device(s) found
twister = usb reset
(Re)start USB...
USB: Register 1313 NbrPorts 3
USB EHCI 1.00
scanning bus for devices... 1 USB Device(s) found
scanning bus for storage devices... 0 Storage Device(s) found
Yes it was a typo and Looks like the corrected patch was not picked up
as in here:
http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/124620
FWIW
Acked-by: Govindraj.R govindraj.raja at ti.com
Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
---
drivers/usb/host/ehci-omap.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 00f787f..1ed7710 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -200,12 +200,12 @@ int omap_ehci_hcd_init(struct omap_usbhs_board_data
*usbhs_pdata)
if (is_ehci_phy_mode(usbhs_pdata-port_mode[1]))
clrbits_le32(reg, OMAP_UHH_HOSTCONFIG_ULPI_P2_BYPASS);
else
- setbits_le32(reg,
OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS);
+ setbits_le32(reg,
OMAP_UHH_HOSTCONFIG_ULPI_P2_BYPASS);
if (is_ehci_phy_mode(usbhs_pdata-port_mode[2]))
clrbits_le32(reg, OMAP_UHH_HOSTCONFIG_ULPI_P3_BYPASS);
else
- setbits_le32(reg,
OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS);
+ setbits_le32(reg,
OMAP_UHH_HOSTCONFIG_ULPI_P3_BYPASS);
} else if (rev == OMAP_USBHS_REV2) {
clrsetbits_le32(reg, (OMAP_P1_MODE_CLEAR |
OMAP_P2_MODE_CLEAR),
OMAP4_UHH_HOSTCONFIG_APP_START_CLK);
--
1.7.5.4
___
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] usb ethernet working on panda?
On Wed, Feb 29, 2012 at 4:47 AM, Kumar Gala ga...@kernel.crashing.org wrote: Does anyone have usb ethernet working on top of git tree on a panda board? yes. If so any gotcha's or details on how you have it working. I use following commands: setenv usbethaddr 0:0:1:2:3:4;usb start; After Ethernet enumerates, from u-boot I use following bootargs setenv ipaddr xxx.xxx.xxx.xxx;setenv serverip xxx.xxx.xxx.xxx;setenv gatewayip xxx.xxx.xxx.xxx;setenv netmask xxx.xxx.xxx.xx; setenv bootfile xx;setenv bootcmd 'tftp 8030;bootm 8030'; setenv bootargs console=ttyO2,115200n8 noinitrd root=/dev/nfs rw nfsroot=path_to_fs,nolock,tcp, wsize=1024,rsize=1024 ip=dhcp devfs=mount; boot; Ensure you have smsc95xx usb Ethernet adapter support in your kernel for nfs boot. -- Thanks, Govindraj.R ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/4] Clean up ehci-omap and extend support for omap3/4 socs
Hi Marek, On Mon, Feb 27, 2012 at 4:43 AM, Marek Vasut ma...@denx.de wrote: From: Govindraj.R govindraj.r...@ti.com Clean up ehci-omap added and make it generic to extend support for omap4 socs. Add ehci support for panda board. Patch series depends on below patch: http://patchwork.ozlabs.org/patch/130952/ Patch series based commit id: 9a4209869bd2c37affd931d627b3c3e72952 This patch series long with above dependent patch is avialable at: git://gitorious.org/denx_u-boot/denx_uboot_omap.git v2_ehci_omap4 Fatls, ping and tftp was tested with this patch series. Test log for Panda available here: http://pastebin.pandaboard.org/index.php/view/55361716 Test log for Beagle-XM available here: http://pastebin.pandaboard.org/index.php/view/98437825 Hi, what's the status of this patch/patchset? It's merged. ubnuser@ula0131859:~/clones/mainline_loaders/u-boot$ gls dd54d31..49be71c 49be71c OMAP4: ehci-omap: enable ehci-omap for panda boards (2 weeks ago) 860004c OMAP4: clock-common: Move the usb dppl configuration to new func (2 weeks ago) 95f8791 OMAP3+: Clock: Adding ehci clock enabling (2 weeks ago) 43b6239 ehci-omap: Clean up added ehci-omap.c (2 weeks ago) 29321c0 ehci-omap: driver for EHCI host on OMAP3 (2 weeks ago) 928c4bd usb: ulpi: Add omap-ulpi-view port support (2 weeks ago) 3e6e809 usb: ulpi: Extend the existing ulpi framework. (2 weeks ago) -- Thanks, Govindraj.R ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP USB, beagle-xm fail
Hi Peter, On Mon, Feb 13, 2012 at 1:52 PM, Peter Meerwald pme...@pmeerw.net wrote: Hello, the recent OMAP USB changes (43b62393da6dfdd7f503d1b37344463a05ea47b5, 29321c0518d99494ab2a250e5b4f75b3add83b11) fail on beagleboard-xm rev. C, see below The errors have nothing to do with ehci patch merges, (I had tested it on beagle rev c board before posting it out) Looking into it closely the below two patches are causing this issue: [...] commit 498cbdfe62a8330f6c89765bdd15e60328a26511 Author: Patil, Rachna rac...@ti.com Date: Sun Jan 22 23:46:23 2012 + ARM: AM33XX: Add AM33XX I2C driver support commit 2faa76196af4b3e93bcb9e38ed9090cbd3b06db3 Author: Patil, Rachna rac...@ti.com Date: Sun Jan 22 23:44:12 2012 + ARM: I2C: I2C Multi byte address support [...] Reverting these two patches I don't see these errors on my beagle rev c board logs as in here [1] btw, usb error printed is a musb error not the ehci host error. -- Thanks, Govindraj.R [1]: U-Boot SPL 2011.12-00325-g146ff78 (Feb 13 2012 - 14:18:55) Texas Instruments Revision detection unimplemented OMAP SD/MMC: 0 timed out in wait_for_bb: I2C_STAT=1000 reading u-boot.img reading u-boot.img U-Boot 2011.12-00325-g146ff78 (Feb 13 2012 - 14:18:55) OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz OMAP3 Beagle board + LPDDR/NAND I2C: ready DRAM: 512 MiB NAND: 0 MiB MMC: OMAP SD/MMC: 0 *** Warning - readenv() failed, using default environment In:serial Out: serial Err: serial Beagle xM Rev C No EEPROM on expansion board Die ID #79e200229ff80163810c0d021023 Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 0 OMAP3 beagleboard.org # OMAP3 beagleboard.org # setenv usbethaddr 0:0:1:2:3:4;usb start; (Re)start USB... USB: Register 1313 NbrPorts 3 USB EHCI 1.00 scanning bus for devices... 3 USB Device(s) found scanning bus for storage devices... 0 Storage Device(s) found scanning bus for ethernet devices... 1 Ethernet Device(s) found OMAP3 beagleboard.org # regards, p. U-Boot SPL 2011.12-00326-gdda8078 (Feb 13 2012 - 09:15:55) Texas Instruments Revision detection unimplemented OMAP SD/MMC: 0 timed out in wait_for_status_mask: I2C_STAT=1010 timed out in wait_for_status_mask: I2C_STAT=1010 reading u-boot.img reading u-boot.img U-Boot 2011.12-00326-gdda8078 (Feb 13 2012 - 09:15:55) OMAP36XX/37XX-GP ES1.2, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz OMAP3 Beagle board + LPDDR/NAND I2C: ready DRAM: 512 MiB NAND: 0 MiB MMC: OMAP SD/MMC: 0 *** Warning - readenv() failed, using default environment timed out in wait_for_status_mask: I2C_STAT=1410 timed out in wait_for_status_mask: I2C_STAT=1410 timed out in wait_for_status_mask: I2C_STAT=1410 timed out in wait_for_status_mask: I2C_STAT=1410 timed out in wait_for_status_mask: I2C_STAT=1410 timed out in wait_for_status_mask: I2C_STAT=1410 timed out in wait_for_status_mask: I2C_STAT=1410 timed out in wait_for_status_mask: I2C_STAT=1410 timed out in wait_for_status_mask: I2C_STAT=1410 timed out in wait_for_status_mask: I2C_STAT=1410 timed out in wait_for_status_mask: I2C_STAT=1410 timed out in wait_for_status_mask: I2C_STAT=1410 TWL4030:USB:Write[0xfd] Error 1 timed out in wait_for_status_mask: I2C_STAT=1410 TWL4030:USB:Write[0xfe] Error 1 timed out in wait_for_status_mask: I2C_STAT=1410 TWL4030:USB:Write[0xfe] Error 1 -- Peter Meerwald +43-664-218 (mobile) ___ 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 v3 6/7] usb: ulpi: Extend the existing ulpi framework.
Hi Subhashini, On Wed, Feb 8, 2012 at 11:12 PM, SUBHASHINI MANNE subbusi...@gmail.com wrote: Govindraj, I have Gumstix overo board with OM3730 + USB 3326 USB PHY.I want to add EHCI and ULPI support in u-boot. You can refer to the v4 patch series posted earlier: http://www.mail-archive.com/u-boot@lists.denx.de/msg76860.html This patch series adds support for omap4_panda using the ehci-omap framework, You can refer to panda board file change on how to do it. Or you also refer to this patch adding support for OMAP3: TAM3517 http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/124645 Something similar needs to be done for your board file to support ehci. Once we port the EHCI_OMAP EHCI driver How to test this driver functionality under u-boot environment? usb start; usb info; usb tree; some commands to check if your downstream device is getting enumerated. refer to usb help in u-boot for usage. you can also use fatls and other use case if you have a hub connected to you root port or you can also check for tftpboot if you have ethernet controller over ehci (like in panda or beagle). care to update your config file for usb ehci enabling (refer to v4 patch series as done for panda/beagle) Is there any application/commands to test ULPI functionality under u-boot environment? what kind of ulpi functionality do you want to test omap-ulpi-viewport is basically for the ulpi phy access from INSNREG05_ULPI from ehci reg map to configure and debug phy interface. (chapter 22.2.2.3 ULPI Interfaces from omap36xx TRM v1.x vW) You can refer to OMAP TRM chapter 22.2 High-Speed USB Host Subsystem for reference. -- Thanks, Govindraj.R ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: TAM3517: update ehci interface
Hi Stefano,
On Tue, Feb 7, 2012 at 9:03 PM, Stefano Babic sba...@denx.de wrote:
On 07/02/2012 16:13, Stefano Babic wrote:
This is a strange effect. I have tested setting OMAP_EHCI_PORT_MODE_PHY
(of course the phy is on another port), and everything works. However,
after setting port_mode[2] to OMAP_USBHS_PORT_MODE_NONE, it does not
work anymore and no storage are detected. I have not an explanation,
maybe some of you can give some hints. Really, the change should have no
effect...
I get the cause in ehci-omap.c:
rev = readl(uhh-rev);
if (rev == OMAP_USBHS_REV1) {
if (is_ehci_phy_mode(usbhs_pdata-port_mode[0]))
clrbits_le32(reg, OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS);
else
setbits_le32(reg, OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS);
if (is_ehci_phy_mode(usbhs_pdata-port_mode[1]))
clrbits_le32(reg, OMAP_UHH_HOSTCONFIG_ULPI_P2_BYPASS);
else
setbits_le32(reg, OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS);
if (is_ehci_phy_mode(usbhs_pdata-port_mode[2]))
clrbits_le32(reg, OMAP_UHH_HOSTCONFIG_ULPI_P3_BYPASS);
else
setbits_le32(reg, OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS);
^--but these should be cleared for port 0
So if PORT2 is set to unused, as it should be and discovered by Igor,
omap_ehci_hcd_init sets OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS against port 0.
Looks like this is copy paste error from my side,
(for port2/3 it should have been bypass for port2/3 rather its port1
set in bypass mode)
I will correct this part and repost the patch.
Thanks for catching this.
--
Thanks,
Govindraj.R
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/7] ehci-omap: Clean up added ehci-omap.c
CREDITS for list of people who contributed to this - * project. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation; either version 2 of - * the License, or (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, - * MA 02110-1301 USA - */ -#ifndef _EHCI_OMAP3_H_ -#define _EHCI_OMAP3_H_ - -/* USB/EHCI registers */ -#define OMAP3_USBTLL_BASE 0x48062000UL -#define OMAP3_UHH_BASE 0x48064000UL -#define OMAP3_EHCI_BASE0x48064800UL - -/* TLL Register Set */ -#defineOMAP_USBTLL_SYSCONFIG (0x10) -#defineOMAP_USBTLL_SYSCONFIG_SOFTRESET (1 1) -#defineOMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 2) -#defineOMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 3) -#defineOMAP_USBTLL_SYSCONFIG_CACTIVITY (1 8) - -#defineOMAP_USBTLL_SYSSTATUS (0x14) -#defineOMAP_USBTLL_SYSSTATUS_RESETDONE (1 0) - -/* UHH Register Set */ -#defineOMAP_UHH_SYSCONFIG (0x10) -#defineOMAP_UHH_SYSCONFIG_SOFTRESET(1 1) -#defineOMAP_UHH_SYSCONFIG_CACTIVITY(1 8) -#defineOMAP_UHH_SYSCONFIG_SIDLEMODE(1 3) -#defineOMAP_UHH_SYSCONFIG_ENAWAKEUP(1 2) -#defineOMAP_UHH_SYSCONFIG_MIDLEMODE(1 12) - -#defineOMAP_UHH_HOSTCONFIG (0x40) -#define OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN (1 2) -#define OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN (1 3) -#define OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN(1 4) - -#endif /* _EHCI_OMAP3_H_ */ diff --git a/arch/arm/include/asm/arch-omap4/ehci.h b/arch/arm/include/asm/arch-omap4/ehci.h new file mode 100644 index 000..984c8b9 --- /dev/null +++ b/arch/arm/include/asm/arch-omap4/ehci.h @@ -0,0 +1,49 @@ +/* + * OMAP EHCI port support + * Based on LINUX KERNEL + * drivers/usb/host/ehci-omap.c and drivers/mfd/omap-usb-host.c + * + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com + * Author: Govindraj R govindraj.r...@ti.com + * + * This program is free software: you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 of + * the License as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see http://www.gnu.org/licenses/. + */ + +#ifndef _OMAP4_EHCI_H_ +#define _OMAP4_EHCI_H_ + +#define OMAP_EHCI_BASE (OMAP44XX_L4_CORE_BASE + 0x64C00) +#define OMAP_UHH_BASE (OMAP44XX_L4_CORE_BASE + 0x64000) +#define OMAP_USBTLL_BASE (OMAP44XX_L4_CORE_BASE + 0x62000) + +/* UHH, TLL and opt clocks */ +#define CM_L3INIT_HSUSBHOST_CLKCTRL0x4A009358UL + +#define HSUSBHOST_CLKCTRL_CLKSEL_UTMI_P1_MASK (1 24) + +/* TLL Register Set */ +#define OMAP_USBTLL_SYSCONFIG_SIDLEMODE(1 3) +#define OMAP_USBTLL_SYSCONFIG_ENAWAKEUP(1 2) +#define OMAP_USBTLL_SYSCONFIG_SOFTRESET(1 1) +#define OMAP_USBTLL_SYSCONFIG_CACTIVITY(1 8) +#define OMAP_USBTLL_SYSSTATUS_RESETDONE1 + +#define OMAP_UHH_SYSCONFIG_SOFTRESET 1 +#define OMAP_UHH_SYSSTATUS_EHCI_RESETDONE (1 2) +#define OMAP_UHH_SYSCONFIG_NOIDLE (1 2) +#define OMAP_UHH_SYSCONFIG_NOSTDBY (1 4) + +#define OMAP_UHH_SYSCONFIG_VAL (OMAP_UHH_SYSCONFIG_NOIDLE | \ + OMAP_UHH_SYSCONFIG_NOSTDBY) + +#endif /* _OMAP4_EHCI_H_ */ diff --git a/arch/arm/include/asm/ehci-omap.h b/arch/arm/include/asm/ehci-omap.h new file mode 100644 index 000..e72c5df --- /dev/null +++ b/arch/arm/include/asm/ehci-omap.h @@ -0,0 +1,142 @@ +/* + * OMAP EHCI port support + * Based on LINUX KERNEL + * drivers/usb/host/ehci-omap.c and drivers/mfd/omap-usb-host.c + * + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
Re: [U-Boot] [PATCH v3 6/7] usb: ulpi: Extend the existing ulpi framework.
Hi Igor,
On Mon, Feb 6, 2012 at 2:25 PM, Igor Grinberg grinb...@compulab.co.il wrote:
Hi Govindraj,
I was about to ask Tom to reorder the patches while applying, but
there are still several things to fix.
I'm also fine with fixing these by a follow up patch (after merging this).
[...]
[...]
diff --git a/drivers/usb/ulpi/ulpi-viewport.c
b/drivers/usb/ulpi/ulpi-viewport.c
index 490fb0e..6f03f08 100644
--- a/drivers/usb/ulpi/ulpi-viewport.c
+++ b/drivers/usb/ulpi/ulpi-viewport.c
[...]
-int ulpi_write(u32 ulpi_viewport, u8 *reg, u32 value)
+int ulpi_write(struct ulpi_viewport *ulpi_vp, u8 *reg, u32 value)
{
u32 val = ULPI_RWRUN | ULPI_RWCTRL | ((u32)reg 16) | (value 0xff);
You should utilize the port_num variable here, right?
something like:
val |= (ulpi_vp-port_num 0x7) 24;
Yes correct, Shouldn't we add something like this
[...]
#ifndef CONFIG_ULPI_PORT_SHIFT CONFIG_ULPI_PORT_MASK
#define CONFIG_ULPI_PORT_SHIFT 24
#define CONFIG_ULPI_PORT_MASK 0x7
#endif
[...]
val |= (ulpi_vp-port_num CONFIG_ULPI_PORT_MASK)
CONFIG_ULPI_PORT_SHIFT;
- return ulpi_request(ulpi_viewport, val);
+ return ulpi_request(ulpi_vp, val);
}
-u32 ulpi_read(u32 ulpi_viewport, u8 *reg)
+u32 ulpi_read(struct ulpi_viewport *ulpi_vp, u8 *reg)
{
int err;
u32 val = ULPI_RWRUN | ((u32)reg 16);
same here
- err = ulpi_request(ulpi_viewport, val);
+ err = ulpi_request(ulpi_vp, val);
if (err)
return err;
- return (readl(ulpi_viewport) 8) 0xff;
+ return (readl(ulpi_vp-viewport_addr) 8) 0xff;
}
[...]
diff --git a/include/usb/ulpi.h b/include/usb/ulpi.h
index 802f077..a036bab 100644
--- a/include/usb/ulpi.h
+++ b/include/usb/ulpi.h
@@ -28,12 +28,23 @@
#endif
/*
+ * ulpi view port address and
+ * Port_number that can be passed.
+ * Any additional data to be passed can
+ * be extended from this structure
+ */
+struct ulpi_viewport {
+ u32 viewport_addr;
+ u8 port_num;
+};
haven't we aggreed, that this will be:
u32 port_num;
My bad I missed this will correct now.
?
+
+/*
* Initialize the ULPI transciever and check the interface integrity.
- * @ulpi_viewport - the address of the ULPI viewport register.
+ * @ulpi_viewport - structure containing ULPI viewport data
This is ulpi_vp now.
will correct this.
--
Thanks,
Govindraj.R
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/7] OMAP3+: Clock: Adding ehci clock enabling
On Mon, Feb 6, 2012 at 5:12 PM, Igor Grinberg grinb...@compulab.co.il wrote: On 02/03/12 15:38, Govindraj.R wrote: From: Govindraj.R govindraj.r...@ti.com Adding ehci clock enabling mechanism part of clock framework. When essential clocks are enabled during init phase usb host clocks can also be enabled from clock framework. Signed-off-by: Govindraj.R govindraj.r...@ti.com Acked-by: Igor Grinberg grinb...@compulab.co.il --- arch/arm/cpu/armv7/omap3/board.c | 4 arch/arm/cpu/armv7/omap3/clock.c | 20 arch/arm/cpu/armv7/omap4/clocks.c | 5 + arch/arm/include/asm/arch-omap3/sys_proto.h | 1 + 4 files changed, 30 insertions(+), 0 deletions(-) diff --git a/arch/arm/cpu/armv7/omap3/board.c b/arch/arm/cpu/armv7/omap3/board.c index 871aa37..054e9c4 100644 --- a/arch/arm/cpu/armv7/omap3/board.c +++ b/arch/arm/cpu/armv7/omap3/board.c @@ -228,6 +228,10 @@ void s_init(void) per_clocks_enable(); +#ifdef CONFIG_USB_EHCI_OMAP + ehci_clocks_enable(); +#endif Just a question (not blocking): I would really like to see this being a part of usb start call some day... Can't this be called from omap_ehci_hcd_init()? But its better to have it part of clock framework. on omap4 I have added this part of enabling essential clocks done part of clock framework. arch/arm/cpu/armv7/omap[4/5]/clocks.c = arch/arm/cpu/armv7/omap-common/clocks-common.c but on omap3 we don't seem to use clocks common. so I have just used this function. on omap4/5 clocks.c makes things simpler for us. (re-use the same rather to complicate with our funcs) -- Thanks, Govindraj.R ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c
Hi Igor,
Sorry for late reply, Was really busy with some other tasks.
On Sun, Jan 29, 2012 at 3:12 PM, Igor Grinberg grinb...@compulab.co.il wrote:
Hi Govindraj,
Put Remy on Cc.
Yes Sure,
Note: my new mail client for some reason, messes with white spaces...
(Thunderbird (9) just gets better and better...)
So, please ignore those.
BTW, is there anyone who has those issues fixed and can save me a wasted
hour?
[...]
Ok, I think you should split this patch to:
1) modify the ulpi framework... (this one extends the ulpi functionality
and fixes current users)
2) add omap ulpi support (this one makes use of the ulpi framework
on omap platforms and IMO, should amended to you original
1/4 patch: ehci-omap: Clean up added ehci-omap.c)
Yes Correct, I have done that will be posting the complete
series in short while.
Tested on beagle-xm and Panda.
Compile tested on efikamx platform.
This patch is based on earlier posted patch series[1].
Shouldn't this be [2]?
yes correct my mistake.
Prior to this patch ulpi reset was done directly now
it is done using ulpi_reset.
Thanks to Igor Grinberggrinb...@compulab.co.il for reviewing the
omap-ehci patches and suggesting this approach.
This patch along with the patch series [1] rebased on latest u-boot
Probably same here, or am I mistaken?
yes you are right, it should be [2]
is available here.
git://gitorious.org/denx_u-boot/denx_uboot_omap.git v2_ehci_omap4
[1]: http://www.mail-archive.com/u-boot@lists.denx.de/msg76076.html
[2]: [PATCH v2 0/4] Clean up ehci-omap and extend support for omap3/4
socs
Signed-off-by: Govindraj.Rgovindraj.r...@ti.com
---
board/efikamx/efikamx-usb.c | 21 ---
drivers/usb/host/ehci-omap.c | 21 ++-
drivers/usb/ulpi/Makefile | 1 +
drivers/usb/ulpi/omap-ulpi-viewport.c | 110
+
drivers/usb/ulpi/ulpi-viewport.c | 30 +-
drivers/usb/ulpi/ulpi.c | 54
include/configs/omap3_beagle.h | 3 +
include/configs/omap4_panda.h | 2 +
include/usb/ulpi.h | 37
You should also, update the README file with the new
CONFIG_USB_ULPI_VIEWPORT_OMAP option.
(Also may be some OMAP specific doc files..)
yes fine, I am adding a new doc
README.omap-ulpi-viewport
and adding some minimal info on the omap-ulpi-viewport
usage and usecase.
9 files changed, 202 insertions(+), 77 deletions(-)
create mode 100644 drivers/usb/ulpi/omap-ulpi-viewport.c
diff --git a/board/efikamx/efikamx-usb.c b/board/efikamx/efikamx-usb.c
index 840bd9a..bb1398b 100644
--- a/board/efikamx/efikamx-usb.c
+++ b/board/efikamx/efikamx-usb.c
@@ -120,6 +120,7 @@ static void efika_ehci_init(struct usb_ehci *ehci,
uint32_t stp_gpio,
{
int ret;
struct ulpi_regs *ulpi = (struct ulpi_regs *)0;
+ struct ulpi_viewport ulpi_vp;
mxc_request_iomux(stp_gpio, alt0);
mxc_iomux_set_pad(stp_gpio, PAD_CTL_DRV_HIGH |
@@ -133,23 +134,25 @@ static void efika_ehci_init(struct usb_ehci
*ehci, uint32_t stp_gpio,
mxc_iomux_set_pad(stp_gpio, USB_PAD_CONFIG);
udelay(1);
- ret = ulpi_init((u32)ehci-ulpi_viewpoint);
+ ulpi_vp.viewport_addr = (u32)ehci-ulpi_viewpoint;
here, you should also:
+ ulpi_vp.port_num = 0;
okay.
because the ulpi_vp structure is not initialized and can have garbage in it.
+
+ ret = ulpi_init(ulpi_vp);
if (ret) {
printf(Efika USB ULPI initialization failed\n);
return;
}
/* ULPI set flags */
- ulpi_write((u32)ehci-ulpi_viewpoint,ulpi-otg_ctrl,
+ ulpi_write(ulpi_vp,ulpi-otg_ctrl,
ULPI_OTG_DP_PULLDOWN | ULPI_OTG_DM_PULLDOWN |
ULPI_OTG_EXTVBUSIND);
- ulpi_write((u32)ehci-ulpi_viewpoint,ulpi-function_ctrl,
+ ulpi_write(ulpi_vp,ulpi-function_ctrl,
ULPI_FC_FULL_SPEED | ULPI_FC_OPMODE_NORMAL |
ULPI_FC_SUSPENDM);
- ulpi_write((u32)ehci-ulpi_viewpoint,ulpi-iface_ctrl, 0);
+ ulpi_write(ulpi_vp,ulpi-iface_ctrl, 0);
/* Set VBus */
- ulpi_write((u32)ehci-ulpi_viewpoint,ulpi-otg_ctrl_set,
+ ulpi_write(ulpi_vp,ulpi-otg_ctrl_set,
ULPI_OTG_DRVVBUS | ULPI_OTG_DRVVBUS_EXT);
/*
@@ -158,7 +161,7 @@ static void efika_ehci_init(struct usb_ehci *ehci,
uint32_t stp_gpio,
* NOTE: This violates USB specification, but otherwise, USB on
Efika
* doesn't work.
*/
- ulpi_write((u32)ehci-ulpi_viewpoint,ulpi-otg_ctrl_set,
+ ulpi_write(ulpi_vp,ulpi-otg_ctrl_set,
ULPI_OTG_CHRGVBUS);
This fits 80 characters, right? Can this now be on the same line?
sure.
}
@@ -177,9 +180,11 @@ void ehci_powerup_fixup(uint32_t *status_reg,
uint32_t *reg
Re: [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c
On Sun, Jan 29, 2012 at 5:12 PM, Stefano Babic sba...@denx.de wrote: On 29/01/2012 10:42, Igor Grinberg wrote: Hi Govindraj, Hi all, Put Remy on Cc. Remy resigned as USB maintainer - but Tom is aware about these patches... Note: my new mail client for some reason, messes with white spaces... (Thunderbird (9) just gets better and better...) I had the opposite problem - this patch from patchwork is messy. Patchworks mixed some answer with the patch and it is not appliable. But using Thunderbird 9 I had no problem... So, please ignore those. BTW, is there anyone who has those issues fixed and can save me a wasted hour? I do not know exactly your problem, but I pushed my tree for TAM3517 on git.denx.de/u-boot-imx, spl_linux_twister branch Maybe this can help you diff --git a/include/configs/omap4_panda.h b/include/configs/omap4_panda.h index 23c0230..0228a66 100644 --- a/include/configs/omap4_panda.h +++ b/include/configs/omap4_panda.h @@ -38,6 +38,8 @@ #define CONFIG_USB_HOST #define CONFIG_USB_EHCI #define CONFIG_USB_EHCI_OMAP +#define CONFIG_USB_ULPI +#define CONFIG_USB_OMAP_ULPI_VIEWPORT #define CONFIG_USB_STORAGE #define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3 This also should apply for TAM3517 board. Stefano, can you test this on TAM3517? Tested on twister / TAM3517, I can read a USB pen. Tested-by: Stefano Babic sba...@denx.de Thanks for testing I have added your tested by after splitting this into two patches as per Igor Grinberg grinb...@compulab.co.il comments. -- Thanks, Govindraj.R ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] ehci-omap: driver for EHCI host on OMAP3
On Thu, Jan 26, 2012 at 2:19 AM, Tom Rini tom.r...@gmail.com wrote: On Wed, Jan 25, 2012 at 3:32 AM, Stefano Babic sba...@denx.de wrote: On 17/01/2012 07:14, Govindraj wrote: On Mon, Jan 16, 2012 at 3:27 PM, Stefano Babic sba...@denx.de wrote: On 16/01/2012 08:58, Govindraj wrote: Th v2 patch series [1] posted is based on top of this patch. If I understand well, we need in any case Ilya's patch. In this case, it is maybe worth to merge Ilya's patch in the meanwhile (and please drop my patch that remove USB support from TAM3517 boards). Yes correct we have to pull in this patch. Tom, Will you be taking this through omap tree? Tom, do you see any problem about merging this patch ? It fixes the build problem on the mt_ventoux board, and there is still a Ilya's patch (mcx: support for HTKW mcx board) waiting for it http://patchwork.ozlabs.org/patch/131431/ My only concern is that I would really like to wait for the cleanup / fixup series to be complete before we pull this change in as well. Yes thanks, I am working on some comments from Igor to make use of ulpi frame work for soft phy reset for ulpi phy. (reference: http://www.mail-archive.com/u-boot@lists.denx.de/msg76076.html) Will shortly repost the changes along with this patch re-based on latest commit. -- Thanks, Govindraj.R ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c
On Wed, Jan 25, 2012 at 7:10 PM, Igor Grinberg grinb...@compulab.co.il wrote:
Hi Govindraj,
On 01/25/12 11:04, Govindraj wrote:
Hi Igor,
On Sun, Jan 22, 2012 at 5:50 PM, Igor Grinberg grinb...@compulab.co.il
wrote:
On 01/19/12 10:15, Govindraj wrote:
On Wed, Jan 18, 2012 at 11:21 PM, Igor Grinberg grinb...@compulab.co.il
wrote:
Hi Govindraj,
On 01/17/12 08:10, Govindraj wrote:
[...]
and add an ability to pass some kind of private data to the viewport,
which
in case of OMAP will be the port number.
I started on adding omap-ulpi-viewport.c which will work with ulpi.c
if omap_ehci.c is used.
Good! Thanks for working on that.
for port id can we just set a global data field that will inform the
omap_view port
on the port id, or we have to modify most api's syntax in
drivers/usb/ulpi/ulpi.c
IMO, we should modify the API, because it does not make sense
to use the generic layer, but workaround some missing feature...
My suggestion for the change is:
1) introduce some kind of
struct ulpi_viewport {
u32 viewport_addr;
uint portnum;
}
2) use the above struct _instead_ of the u32 ulpi_viewport parameter
Another way, would be instead of uint portnum, use void *private_data,
but I think it will just complicate things too much and there will be no
real benefit (and also will add, otherwise needless, castings).
If the above structure will not be enough for some platform,
it can be extended easily and without changing the API anymore.
Thanks for the suggestions.
Here [1] is the first attempt to implement the same.
sorry for late reply, as I was preempted with some other work.
--
Thanks,
Govindraj.R
[1]:
From 2bc311c26572aff3ebaac035106434b444692f68 Mon Sep 17 00:00:00 2001
From: Govindraj.R govindraj.r...@ti.com
Date: Fri, 27 Jan 2012 18:34:11 +0530
Subject: [PATCH] ulpi: Modify the ulpi framework to accept port number
Based on discussion in the thread [1] this patch
attempts to modify the ulpi framework to accept the
port number along with view port address, adding the omap-ulpi
view port that helps us in using the generic ulpi
framework to configure ulpi phy using the INSNREG05_ULPI viewport
reg available on omap platform.
Tested on beagle-xm and Panda.
Compile tested on efikamx platform.
This patch is based on earlier posted patch series[1].
Prior to this patch ulpi reset was done directly now
it is done using ulpi_reset.
Thanks to Igor Grinberg grinb...@compulab.co.il for reviewing the
omap-ehci patches and suggesting this approach.
This patch along with the patch series [1] rebased on latest u-boot
is available here.
git://gitorious.org/denx_u-boot/denx_uboot_omap.git v2_ehci_omap4
[1]: http://www.mail-archive.com/u-boot@lists.denx.de/msg76076.html
[2]: [PATCH v2 0/4] Clean up ehci-omap and extend support for omap3/4 socs
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
board/efikamx/efikamx-usb.c | 21 ---
drivers/usb/host/ehci-omap.c | 21 ++-
drivers/usb/ulpi/Makefile |1 +
drivers/usb/ulpi/omap-ulpi-viewport.c | 110 +
drivers/usb/ulpi/ulpi-viewport.c | 30 +-
drivers/usb/ulpi/ulpi.c | 54
include/configs/omap3_beagle.h|3 +
include/configs/omap4_panda.h |2 +
include/usb/ulpi.h| 37
9 files changed, 202 insertions(+), 77 deletions(-)
create mode 100644 drivers/usb/ulpi/omap-ulpi-viewport.c
diff --git a/board/efikamx/efikamx-usb.c b/board/efikamx/efikamx-usb.c
index 840bd9a..bb1398b 100644
--- a/board/efikamx/efikamx-usb.c
+++ b/board/efikamx/efikamx-usb.c
@@ -120,6 +120,7 @@ static void efika_ehci_init(struct usb_ehci *ehci,
uint32_t stp_gpio,
{
int ret;
struct ulpi_regs *ulpi = (struct ulpi_regs *)0;
+ struct ulpi_viewport ulpi_vp;
mxc_request_iomux(stp_gpio, alt0);
mxc_iomux_set_pad(stp_gpio, PAD_CTL_DRV_HIGH |
@@ -133,23 +134,25 @@ static void efika_ehci_init(struct usb_ehci
*ehci, uint32_t stp_gpio,
mxc_iomux_set_pad(stp_gpio, USB_PAD_CONFIG);
udelay(1);
- ret = ulpi_init((u32)ehci-ulpi_viewpoint);
+ ulpi_vp.viewport_addr = (u32)ehci-ulpi_viewpoint;
+
+ ret = ulpi_init(ulpi_vp);
if (ret) {
printf(Efika USB ULPI initialization failed\n);
return;
}
/* ULPI set flags */
- ulpi_write((u32)ehci-ulpi_viewpoint, ulpi-otg_ctrl,
+ ulpi_write(ulpi_vp, ulpi-otg_ctrl,
ULPI_OTG_DP_PULLDOWN | ULPI_OTG_DM_PULLDOWN |
ULPI_OTG_EXTVBUSIND);
- ulpi_write((u32)ehci-ulpi_viewpoint, ulpi-function_ctrl,
+ ulpi_write(ulpi_vp, ulpi-function_ctrl,
ULPI_FC_FULL_SPEED | ULPI_FC_OPMODE_NORMAL |
ULPI_FC_SUSPENDM);
- ulpi_write((u32)ehci-ulpi_viewpoint, ulpi-iface_ctrl, 0);
+ ulpi_write(ulpi_vp
Re: [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c
Hi Igor,
On Sun, Jan 22, 2012 at 5:50 PM, Igor Grinberg grinb...@compulab.co.il wrote:
On 01/19/12 10:15, Govindraj wrote:
On Wed, Jan 18, 2012 at 11:21 PM, Igor Grinberg grinb...@compulab.co.il
wrote:
Hi Govindraj,
On 01/17/12 08:10, Govindraj wrote:
[...]
+ if (get_timer(init) CONFIG_SYS_HZ) {
+ debug(OMAP EHCI error: timeout resetting phy\n);
+ break;
+ }
+}
Ok, this function is kind of duplication of the ULPI code.
ulpi_reset() function in drivers/usb/ulpi/ulpi.c provides an implementation
of the ULPI spec. and should be used by the drivers.
What it lacks currently, is a way to pass a port number to the viewport
implementation and of course the omap-ulpi-viewport(.c) implementation
itself...
So, IMO, the right way would be to implement ULPI accessors
(omap-ulpi-viewport.c)
so you mean add omap-ulpi-viewport.c which will do ulpi read writes
for ulpi implementation
within tll module of omap host controller.
No. What I meant is that omap-ulpi-viewport.c will do the ULPI access
to the PHY (which is not TLL), but after the above question, I think
it can do both: TLL and non-TLL.
we just need func reset to be done for ulpi which is done using ehci register
INSNREG05_ULPI. IMHO I don't see any use case or true requirement of
omap-ulpi-viewport.c framework.
The fact that the reset is done by writing the ULPI_FUNC_CTRL_RESET bit
of the ULPI_FUNC_CTRL register - is the requirement...
For example tomorrow, you will find out that besides reset, you also need
to set some other bit in a register inside the ULPI PHY (e.g. VBUS), so
you will implement another ehci function that will do a write to ULPI
and thus duplicate another portion of code...
and add an ability to pass some kind of private data to the viewport, which
in case of OMAP will be the port number.
I started on adding omap-ulpi-viewport.c which will work with ulpi.c
if omap_ehci.c is used.
for port id can we just set a global data field that will inform the
omap_view port
on the port id, or we have to modify most api's syntax in
drivers/usb/ulpi/ulpi.c
Is it okay to have the port id from ehci-omap.c set and used in
drivers/usb/ulpi/omap-ulpi-viewport.c ?
--
Thanks,
Govindraj.R
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c
On Wed, Jan 18, 2012 at 11:21 PM, Igor Grinberg grinb...@compulab.co.il wrote: Hi Govindraj, On 01/17/12 08:10, Govindraj wrote: And just to clarify further there is no code duplication for ulpi read writes in ehci-omap.c done with this patch. This is not just about code duplication, this is also about using the ULPI framework instead of direct writes to the ULPI PHYs. Patch intends only in configuring ehci to right modes as specified by board file. Modes possible are hsic_mode, tll_mode, ulpi_phy mode. This patch is derived with reference to linux kernel and even there we can see that no ulpi_reg map registers are used and only ehci is configured is respective mode as passed by board data. This is not correct. They are used, see: drivers/usb/host/ehci-omap.c file, omap_ehci_soft_phy_reset() function. It does exactly the same, but yes it does not use the ULPI framework, because in Linux currently, there is no generic enough ULPI framework, so drivers can use it. linux-2.6/drivers/usb/otg/ulpi.c ? There were discussions about it and decided that until there is such a framework, things can be done the way they are. Here [1] is the patch fixing Marek Vasut marek.va...@gmail.com comments. This corrected patch along with dependent patch from Ilya Yanok ya...@emcraft.com [PATCH V4 1/2] ehci-omap: driver for EHCI host on OMAP3 Is available here: git://gitorious.org/denx_u-boot/denx_uboot_omap.git v2_ehci_omap -- Thanks, Govindraj.R [1]: From 56b1b94128495ed4bf83e2f20f3884833e2aa082 Mon Sep 17 00:00:00 2001 From: Govindraj.R govindraj.r...@ti.com Date: Tue, 27 Dec 2011 14:53:12 +0530 Subject: [PATCH 2/6] ehci-omap: Clean up added ehci-omap.c Clean up added ehci-omap.c and make it generic for re-use across soc having same ehci ip block. Also pass the modes to be configured and configure the ports accordingly. All usb layers are not cache aligned till then keep cache off for usb ops as ehci will use internally dma for all usb ops. * Add a generic common header ehci-omap.h having common ip block data and reg shifts. * Rename and modify ehci-omap3 to ehci.h retain only conflicting sysc reg shifts remove others and move to common header file. Signed-off-by: Govindraj.R govindraj.r...@ti.com --- arch/arm/include/asm/arch-omap3/ehci.h | 55 ++ arch/arm/include/asm/arch-omap3/ehci_omap3.h | 58 --- arch/arm/include/asm/arch-omap4/ehci.h | 49 ++ arch/arm/include/asm/ehci-omap.h | 147 + drivers/usb/host/ehci-omap.c | 228 +++--- 5 files changed, 423 insertions(+), 114 deletions(-) create mode 100644 arch/arm/include/asm/arch-omap3/ehci.h delete mode 100644 arch/arm/include/asm/arch-omap3/ehci_omap3.h create mode 100644 arch/arm/include/asm/arch-omap4/ehci.h create mode 100644 arch/arm/include/asm/ehci-omap.h diff --git a/arch/arm/include/asm/arch-omap3/ehci.h b/arch/arm/include/asm/arch-omap3/ehci.h new file mode 100644 index 000..d622363 --- /dev/null +++ b/arch/arm/include/asm/arch-omap3/ehci.h @@ -0,0 +1,55 @@ +/* + * (C) Copyright 2011 + * Alexander Holler hol...@ahsoftware.de + * + * Based on drivers/usb/host/ehci-omap.c from Linux 2.6.37 + * + * See there for additional Copyrights. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, + * MA 02110-1301 USA + */ +#ifndef _EHCI_H_ +#define _EHCI_H_ hmmm... isn't it too generic? I think you should have included a part of the path to the file, so no namespace collision will occure. something like _OMAP3_EHCI_H_? since these include's are part of arch folder will not collide with other ones. But still its better to have _OMAP3_EHCI_H_ will correct this. + +/* USB/EHCI registers */ +#define OMAP_USBTLL_BASE 0x48062000UL +#define OMAP_UHH_BASE 0x48064000UL +#define OMAP_EHCI_BASE 0x48064800UL + +/* TLL Register Set */ +#define OMAP_USBTLL_SYSCONFIG_SOFTRESET (1 1) +#define OMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 2) +#define OMAP_USBTLL_SYSCONFIG_SIDLEMODE
Re: [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c
On Thu, Jan 12, 2012 at 4:22 PM, Govindraj govindraj...@gmail.com wrote:
On Thu, Jan 12, 2012 at 2:53 PM, Igor Grinberg grinb...@compulab.co.il
wrote:
Hi Govindraj,
On 01/12/12 07:45, Govindraj wrote:
Hi Igor,
On Wed, Jan 11, 2012 at 8:33 PM, Igor Grinberg grinb...@compulab.co.il
wrote:
Hi Guys,
On 01/11/12 16:34, Marek Vasut wrote:
On Wed, Jan 11, 2012 at 6:58 PM, Marek Vasut marek.va...@gmail.com
wrote:
On Wed, Jan 11, 2012 at 6:16 PM, Marek Vasut marek.va...@gmail.com
wrote:
On Wed, Jan 11, 2012 at 4:22 PM, Marek Vasut marek.va...@gmail.com
wrote:
Hi Marek,
Thanks for you review.
On Tue, Jan 10, 2012 at 9:37 PM, Marek Vasut
marek.va...@gmail.com
wrote:
From: Govindraj.R govindraj.r...@ti.com
Clean up added ehci-omap.c and make it generic for re-use
across soc having same ehci ip block. Also pass the modes to
be configured and configure the ports accordingly. All usb
layers are not cache aligned till then keep cache off for usb
ops as ehci will use internally dma for all usb ops.
* Add a generic common header ehci-omap.h having common ip
block data and reg shifts.
* Rename and modify ehci-omap3 to ehci.h retain only
conflicting sysc reg shifts remove others and move to common
header file.
Don't reimplement the ulpi stuff ... there's already some ulpi
stuff in uboot that needs fixing, so fix it and use it.
I am not implementing any ulpi stuff I am just configuring OMAP on
soc usb host controller (ehci). All the configuration stuff
is OMAP specific things which are done in ehci-omap.c file
stuffs done are like soft-reset, port mode to be used and putting
port in no -idle mode(omap specific pm implementation) etc.
This stuff:
+/* ULPI */
+#define ULPI_SET(a) (a + 1)
+#define ULPI_CLR(a) (a + 2)
+#define ULPI_FUNC_CTRL 0x04
+#define ULPI_FUNC_CTRL_RESET (1 5)
is just accidentally conforming to ULPI spec?
These are for configuring INSNREG05_ULPI reg in EHCI reg map
of omap while configuring in ulpi-phy mode.
looking into struct ulpi_regs {..}
then it doesn't map this configuration.
Can you point me to some documentation about this please? It's not
that I don't trust you, I'd rather prefer to avoid unnecessary
duplication.
Yes that would be fine.
You can download the omap4460 public trm from here:
http://www.ti.com/pdfs/wtbu/OMAP4460_ES.1x_PUBLIC_TRM_vM.zip
Go to chapter 23.11.6.6.1 EHCI Register Summary
(page number 5171 and 5186/87)
Sure, but the macro above looks more like 23.11.6.3, doesn't it ? And
for
that purpose, the struct ulpi_regs is fitting ok.
Actually ... can you check the ulpi_read and ulpi_write stuff that's
already in u-boot and explain why they can not be used with this port?
echi-omap.c is no where writing to those registers
and the macro was used only to configure INSNREG05_ULPI reg in EHCI reg
map
reg map in 23.11.6.3 used only for a external ulpi-phy communication.
and debug purpose(to view vid, pid etc) and to hack external phy
configuration through ulpi commands
from omap - usb host controller point of view only needs
INSNREG05_ULPI reg in EHCI reg configuration
rest on soc host controller takes care of it.
Can someone else comment on this? I think I don't understand well (as I'm
not
OMAP guy).
Well, it is on my list, actually,
but I will be able to get to it only in a couple of days.
(I'm really busy right now).
Could you please let me know what exactly that you will be
updating?
So that I can accordingly post my v3 of this patch fixing comments
from Marek Vasut marek.va...@gmail.com
Well, I did not say, I'm going to update anything.
What I meant is that I'm going to look into TI's documentation
regarding EHCI and the ULPI to understand the dependencies and see
how your code meets those and if the generic ULPI layer can be used
for that.
okay, Thanks,
So to lower the work load from from you, I'd suggest you to wait
till Monday (if you can of course) to let me look into this.
Gentle Ping.
And just to clarify further there is no code duplication for ulpi read writes
in ehci-omap.c done with this patch.
Patch intends only in configuring ehci to right modes as specified by
board file. Modes possible are hsic_mode, tll_mode, ulpi_phy mode.
This patch is derived with reference to linux kernel and even there
we can see that no ulpi_reg map registers are used and only ehci
is configured is respective mode as passed by board data.
Here [1] is the patch fixing Marek Vasut marek.va...@gmail.com
comments.
This corrected patch along with dependent patch from
Ilya Yanok ya...@emcraft.com
[PATCH V4 1/2] ehci-omap: driver for EHCI host on OMAP3
Is available here:
git://gitorious.org/denx_u-boot/denx_uboot_omap.git v2_ehci_omap
--
Thanks,
Govindraj.R
[1]:
From 56b1b94128495ed4bf83e2f20f3884833e2aa082 Mon Sep 17 00:00:00 2001
From
Re: [U-Boot] [PATCH V4 1/2] ehci-omap: driver for EHCI host on OMAP3
On Mon, Jan 16, 2012 at 3:27 PM, Stefano Babic sba...@denx.de wrote: On 16/01/2012 08:58, Govindraj wrote: Th v2 patch series [1] posted is based on top of this patch. If I understand well, we need in any case Ilya's patch. In this case, it is maybe worth to merge Ilya's patch in the meanwhile (and please drop my patch that remove USB support from TAM3517 boards). Yes correct we have to pull in this patch. Tom, Will you be taking this through omap tree? -- Thanks, Govindraj.R ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] ehci-omap: driver for EHCI host on OMAP3
On Mon, Jan 16, 2012 at 3:34 AM, Tom Rini tom.r...@gmail.com wrote: On Sun, Jan 15, 2012 at 1:40 PM, Remy Bohmer li...@bohmer.net wrote: Hi All, 2011/12/22 Ilya Yanok ya...@emcraft.com: Hi Govindraj, On 22.12.2011 10:55, Govindraj wrote: Signed-off-by: Ilya Yanok ya...@emcraft.com --- Changes from V3: - None Changes from V2: - None Changes from V1: - CONFIG_OMAP_EHCI_PHYx_RESET changed to CONFIG_OMAP_EHCI_PHYx_RESET_GPIO - phy reset moved to separate function - Calls to gpio_set_value after gpio_direction_output removed To me the status of this patch is not clear. Do you want this patch to be applied, and than rework the comments in a later patch? Or can we apply a cleaned up ehci-omap patch directly? This has been superseded by Govindraj's series of patches that cover omap3/4. Th v2 patch series [1] posted is based on top of this patch. -- Thanks, Govindraj.R [1]: PATCH v2 0/4] Clean up ehci-omap and extend support for omap3/4 socs http://lists.denx.de/pipermail/u-boot/2012-January/114844.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c
On Wed, Jan 11, 2012 at 4:22 PM, Marek Vasut marek.va...@gmail.com wrote:
Hi Marek,
Thanks for you review.
On Tue, Jan 10, 2012 at 9:37 PM, Marek Vasut marek.va...@gmail.com wrote:
From: Govindraj.R govindraj.r...@ti.com
Clean up added ehci-omap.c and make it generic for re-use across
soc having same ehci ip block. Also pass the modes to be configured
and configure the ports accordingly. All usb layers are not cache
aligned till then keep cache off for usb ops as ehci will use
internally dma for all usb ops.
* Add a generic common header ehci-omap.h having common ip block
data and reg shifts.
* Rename and modify ehci-omap3 to ehci.h retain only conflicting
sysc reg shifts remove others and move to common header file.
Don't reimplement the ulpi stuff ... there's already some ulpi stuff in
uboot that needs fixing, so fix it and use it.
I am not implementing any ulpi stuff I am just configuring OMAP on
soc usb host controller (ehci). All the configuration stuff
is OMAP specific things which are done in ehci-omap.c file
stuffs done are like soft-reset, port mode to be used and putting
port in no -idle mode(omap specific pm implementation) etc.
This stuff:
+/* ULPI */
+#define ULPI_SET(a) (a + 1)
+#define ULPI_CLR(a) (a + 2)
+#define ULPI_FUNC_CTRL 0x04
+#define ULPI_FUNC_CTRL_RESET (1 5)
is just accidentally conforming to ULPI spec?
These are for configuring INSNREG05_ULPI reg in EHCI reg map
of omap while configuring in ulpi-phy mode.
looking into struct ulpi_regs {..}
then it doesn't map this configuration.
btw,
IIUC that ulpi_regs struct is for otg transceiver that uses a ulpi phy chip
for communication.
M
btw. somewhere in the patch is one more asterisk at the end of line:
Will check that
--
Thanks,
Govindraj.R
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c
On Wed, Jan 11, 2012 at 6:16 PM, Marek Vasut marek.va...@gmail.com wrote:
On Wed, Jan 11, 2012 at 4:22 PM, Marek Vasut marek.va...@gmail.com wrote:
Hi Marek,
Thanks for you review.
On Tue, Jan 10, 2012 at 9:37 PM, Marek Vasut marek.va...@gmail.com
wrote:
From: Govindraj.R govindraj.r...@ti.com
Clean up added ehci-omap.c and make it generic for re-use across
soc having same ehci ip block. Also pass the modes to be configured
and configure the ports accordingly. All usb layers are not cache
aligned till then keep cache off for usb ops as ehci will use
internally dma for all usb ops.
* Add a generic common header ehci-omap.h having common ip block
data and reg shifts.
* Rename and modify ehci-omap3 to ehci.h retain only conflicting
sysc reg shifts remove others and move to common header file.
Don't reimplement the ulpi stuff ... there's already some ulpi stuff
in uboot that needs fixing, so fix it and use it.
I am not implementing any ulpi stuff I am just configuring OMAP on
soc usb host controller (ehci). All the configuration stuff
is OMAP specific things which are done in ehci-omap.c file
stuffs done are like soft-reset, port mode to be used and putting
port in no -idle mode(omap specific pm implementation) etc.
This stuff:
+/* ULPI */
+#define ULPI_SET(a) (a + 1)
+#define ULPI_CLR(a) (a + 2)
+#define ULPI_FUNC_CTRL 0x04
+#define ULPI_FUNC_CTRL_RESET (1 5)
is just accidentally conforming to ULPI spec?
These are for configuring INSNREG05_ULPI reg in EHCI reg map
of omap while configuring in ulpi-phy mode.
looking into struct ulpi_regs {..}
then it doesn't map this configuration.
Can you point me to some documentation about this please? It's not that I
don't
trust you, I'd rather prefer to avoid unnecessary duplication.
Yes that would be fine.
You can download the omap4460 public trm from here:
http://www.ti.com/pdfs/wtbu/OMAP4460_ES.1x_PUBLIC_TRM_vM.zip
Go to chapter 23.11.6.6.1 EHCI Register Summary
(page number 5171 and 5186/87)
click INSNREG05_ULPI
this for configuring in ulpi mode for external ulpi phy.
reference
chapter 23.11.4.1 refer to Figure 23-252. HS USB Host Controller Architecture
(page number 5096)
btw,
IIUC that ulpi_regs struct is for otg transceiver that uses a ulpi phy chip
for communication.
M
btw. somewhere in the patch is one more asterisk at the end of line:
Will check that
It was on the line I pointed out
okay, got it.
--
Thanks,
Govindraj.R
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c
On Wed, Jan 11, 2012 at 6:58 PM, Marek Vasut marek.va...@gmail.com wrote:
On Wed, Jan 11, 2012 at 6:16 PM, Marek Vasut marek.va...@gmail.com wrote:
On Wed, Jan 11, 2012 at 4:22 PM, Marek Vasut marek.va...@gmail.com
wrote:
Hi Marek,
Thanks for you review.
On Tue, Jan 10, 2012 at 9:37 PM, Marek Vasut marek.va...@gmail.com
wrote:
From: Govindraj.R govindraj.r...@ti.com
Clean up added ehci-omap.c and make it generic for re-use across
soc having same ehci ip block. Also pass the modes to be
configured and configure the ports accordingly. All usb layers
are not cache aligned till then keep cache off for usb ops as
ehci will use internally dma for all usb ops.
* Add a generic common header ehci-omap.h having common ip block
data and reg shifts.
* Rename and modify ehci-omap3 to ehci.h retain only conflicting
sysc reg shifts remove others and move to common header file.
Don't reimplement the ulpi stuff ... there's already some ulpi
stuff in uboot that needs fixing, so fix it and use it.
I am not implementing any ulpi stuff I am just configuring OMAP on
soc usb host controller (ehci). All the configuration stuff
is OMAP specific things which are done in ehci-omap.c file
stuffs done are like soft-reset, port mode to be used and putting
port in no -idle mode(omap specific pm implementation) etc.
This stuff:
+/* ULPI */
+#define ULPI_SET(a) (a + 1)
+#define ULPI_CLR(a) (a + 2)
+#define ULPI_FUNC_CTRL 0x04
+#define ULPI_FUNC_CTRL_RESET (1 5)
is just accidentally conforming to ULPI spec?
These are for configuring INSNREG05_ULPI reg in EHCI reg map
of omap while configuring in ulpi-phy mode.
looking into struct ulpi_regs {..}
then it doesn't map this configuration.
Can you point me to some documentation about this please? It's not that I
don't trust you, I'd rather prefer to avoid unnecessary duplication.
Yes that would be fine.
You can download the omap4460 public trm from here:
http://www.ti.com/pdfs/wtbu/OMAP4460_ES.1x_PUBLIC_TRM_vM.zip
Go to chapter 23.11.6.6.1 EHCI Register Summary
(page number 5171 and 5186/87)
Sure, but the macro above looks more like 23.11.6.3, doesn't it ? And for that
purpose, the struct ulpi_regs is fitting ok.
Actually ... can you check the ulpi_read and ulpi_write stuff that's already
in
u-boot and explain why they can not be used with this port?
echi-omap.c is no where writing to those registers
and the macro was used only to configure INSNREG05_ULPI reg in EHCI reg map
reg map in 23.11.6.3 used only for a external ulpi-phy communication.
and debug purpose(to view vid, pid etc) and to hack external phy
configuration through ulpi commands
from omap - usb host controller point of view only needs
INSNREG05_ULPI reg in EHCI reg configuration
rest on soc host controller takes care of it.
--
Thanks,
Govindraj.R
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c
Hi Igor,
On Wed, Jan 11, 2012 at 8:33 PM, Igor Grinberg grinb...@compulab.co.il wrote:
Hi Guys,
On 01/11/12 16:34, Marek Vasut wrote:
On Wed, Jan 11, 2012 at 6:58 PM, Marek Vasut marek.va...@gmail.com wrote:
On Wed, Jan 11, 2012 at 6:16 PM, Marek Vasut marek.va...@gmail.com
wrote:
On Wed, Jan 11, 2012 at 4:22 PM, Marek Vasut marek.va...@gmail.com
wrote:
Hi Marek,
Thanks for you review.
On Tue, Jan 10, 2012 at 9:37 PM, Marek Vasut
marek.va...@gmail.com
wrote:
From: Govindraj.R govindraj.r...@ti.com
Clean up added ehci-omap.c and make it generic for re-use
across soc having same ehci ip block. Also pass the modes to
be configured and configure the ports accordingly. All usb
layers are not cache aligned till then keep cache off for usb
ops as ehci will use internally dma for all usb ops.
* Add a generic common header ehci-omap.h having common ip
block data and reg shifts.
* Rename and modify ehci-omap3 to ehci.h retain only
conflicting sysc reg shifts remove others and move to common
header file.
Don't reimplement the ulpi stuff ... there's already some ulpi
stuff in uboot that needs fixing, so fix it and use it.
I am not implementing any ulpi stuff I am just configuring OMAP on
soc usb host controller (ehci). All the configuration stuff
is OMAP specific things which are done in ehci-omap.c file
stuffs done are like soft-reset, port mode to be used and putting
port in no -idle mode(omap specific pm implementation) etc.
This stuff:
+/* ULPI */
+#define ULPI_SET(a) (a + 1)
+#define ULPI_CLR(a) (a + 2)
+#define ULPI_FUNC_CTRL 0x04
+#define ULPI_FUNC_CTRL_RESET (1 5)
is just accidentally conforming to ULPI spec?
These are for configuring INSNREG05_ULPI reg in EHCI reg map
of omap while configuring in ulpi-phy mode.
looking into struct ulpi_regs {..}
then it doesn't map this configuration.
Can you point me to some documentation about this please? It's not
that I don't trust you, I'd rather prefer to avoid unnecessary
duplication.
Yes that would be fine.
You can download the omap4460 public trm from here:
http://www.ti.com/pdfs/wtbu/OMAP4460_ES.1x_PUBLIC_TRM_vM.zip
Go to chapter 23.11.6.6.1 EHCI Register Summary
(page number 5171 and 5186/87)
Sure, but the macro above looks more like 23.11.6.3, doesn't it ? And for
that purpose, the struct ulpi_regs is fitting ok.
Actually ... can you check the ulpi_read and ulpi_write stuff that's
already in u-boot and explain why they can not be used with this port?
echi-omap.c is no where writing to those registers
and the macro was used only to configure INSNREG05_ULPI reg in EHCI reg map
reg map in 23.11.6.3 used only for a external ulpi-phy communication.
and debug purpose(to view vid, pid etc) and to hack external phy
configuration through ulpi commands
from omap - usb host controller point of view only needs
INSNREG05_ULPI reg in EHCI reg configuration
rest on soc host controller takes care of it.
Can someone else comment on this? I think I don't understand well (as I'm not
OMAP guy).
Well, it is on my list, actually,
but I will be able to get to it only in a couple of days.
(I'm really busy right now).
Could you please let me know what exactly that you will be
updating?
So that I can accordingly post my v3 of this patch fixing comments
from Marek Vasut marek.va...@gmail.com
--
Thanks,
Govindraj.R
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c
Hi Marek,
Thanks for you review.
On Tue, Jan 10, 2012 at 9:37 PM, Marek Vasut marek.va...@gmail.com wrote:
From: Govindraj.R govindraj.r...@ti.com
Clean up added ehci-omap.c and make it generic for re-use across
soc having same ehci ip block. Also pass the modes to be configured
and configure the ports accordingly. All usb layers are not cache
aligned till then keep cache off for usb ops as ehci will use
internally dma for all usb ops.
* Add a generic common header ehci-omap.h having common ip block
data and reg shifts.
* Rename and modify ehci-omap3 to ehci.h retain only conflicting
sysc reg shifts remove others and move to common header file.
Don't reimplement the ulpi stuff ... there's already some ulpi stuff in uboot
that needs fixing, so fix it and use it.
I am not implementing any ulpi stuff I am just configuring OMAP on
soc usb host controller (ehci). All the configuration stuff
is OMAP specific things which are done in ehci-omap.c file
stuffs done are like soft-reset, port mode to be used and putting
port in no -idle mode(omap specific pm implementation) etc.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/include/asm/arch-omap3/ehci.h | 55 ++
arch/arm/include/asm/arch-omap3/ehci_omap3.h | 58 ---
arch/arm/include/asm/arch-omap4/ehci.h | 49 ++
arch/arm/include/asm/ehci-omap.h | 147 +
drivers/usb/host/ehci-omap.c | 228
[...]
+
+#ifdef CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS
+#define OMAP_HS_USB_PORTS CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS
+#else
+#define OMAP_HS_USB_PORTS 3
+#endif
+
+#define is_ehci_phy_mode(x) (x == OMAP_EHCI_PORT_MODE_PHY)
+#define is_ehci_tll_mode(x) (x == OMAP_EHCI_PORT_MODE_TLL)
+#define is_ehci_hsic_mode(x) (x == OMAP_EHCI_PORT_MODE_HSIC)
This is unsafe ... use ((x) == ...)
Okay, will correct this.
+
+/* Values of UHH_REVISION - Note: these are not given in the TRM */
+#define OMAP_USBHS_REV1 0x0010 /*
OMAP3 */
+#define OMAP_USBHS_REV2 0x50700100 /*
OMAP4 */
+
[...]
+/* ULPI */
+#define ULPI_SET(a) (a + 1)
+#define ULPI_CLR(a) (a + 2)
ULPI ... use generic stuff
Actually this for omap specific configuration done with omap
reg map.
EHCI register INSNREG05_ULPI needs to be configured if we
are in ulpi-phy mode same is done here.
+#define ULPI_FUNC_CTRL 0x04
+#define ULPI_FUNC_CTRL_RESET (1 5)
+
+struct omap_usbhs_board_data {
+ enum usbhs_omap_port_mode port_mode[OMAP_HS_USB_PORTS];
+};
+
+struct omap_usbtll {
+ u32 rev; /* 0x00 */
+ u32 hwinfo; /* 0x04 */
+ u8 pad1[0x8];
reserved1[] instead of pad1[], fix globally
yes fine, will correct this.
[..]
+struct omap_uhh *const uhh = (struct omap_uhh *)OMAP_UHH_BASE;
+struct omap_usbtll *const usbtll = (struct omap_usbtll *)OMAP_USBTLL_BASE;
+struct omap_ehci *const ehci = (struct omap_ehci *)OMAP_EHCI_BASE;
static
yes correct, will change this.
+
+static int omap_uhh_reset(void)
+{
[...]
+ /* perform TLL soft reset, and wait until reset is complete */
+ writel(OMAP_USBTLL_SYSCONFIG_SOFTRESET, usbtll-sysc);
+
+ /* Wait for TLL reset to complete */
+ while (!(readl(usbtll-syss) OMAP_USBTLL_SYSSTATUS_RESETDONE))
Add timeout, fix globally
Sorry I didn't get you here.
The function uses a timeout value init and then same init
value to used to poll for CONFIG_SYS_HZ time for reset to be
done else prints timeout failure.
+ if (get_timer(init) CONFIG_SYS_HZ) {
+ debug(OMAP EHCI error: timeout resetting TLL\n);
+ return -EL3RST;
+ }
+
[...]
+ /* setup ULPI bypass and burst configurations */
+ reg |= (OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN |
+ OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN |
+ OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN);
+ reg = ~OMAP_UHH_HOSTCONFIG_INCRX_ALIGN_EN;
clrsetbits_le32 ?
yes can be used.
--
Thanks,
Govindraj.R
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] ehci-omap: driver for EHCI host on OMAP3
Hi Igor,
On Thu, Dec 22, 2011 at 1:44 PM, Igor Grinberg grinb...@compulab.co.il wrote:
Hi Govindraj,
On 12/22/11 08:55, Govindraj wrote:
Hi IIya Yanok,
Sorry for late comments.
Better late than never...
On Tue, Dec 13, 2011 at 4:45 AM, Ilya Yanok ya...@emcraft.com wrote:
Taken from Beagle code. Tested on mcx board (AM3517-based).
Signed-off-by: Ilya Yanok ya...@emcraft.com
---
Changes from V3:
- None
Changes from V2:
- None
Changes from V1:
- CONFIG_OMAP_EHCI_PHYx_RESET changed to CONFIG_OMAP_EHCI_PHYx_RESET_GPIO
- phy reset moved to separate function
- Calls to gpio_set_value after gpio_direction_output removed
Here I see lot of stuff are just being moved from beagle board to new file
ehci-omap.c , but echi-omap.c is not generic enough for re-use
I think we should maintain clock handling and any gpio reset in board
file itself
Hmmm, not really...
Current clock handling is SoC specific and not board specific,
so if we are about to make this file generic for more then one
SoC (e.g. OMAP4), then we should also introduce a per SoC clock
handling files, and reuse them with various boards.
Probably the same should hold for the GPIO reset code, because
otherwise code duplication is unavoidable.
yes true,
gpio reset needed for boards having ehci connected to a external hub
can pass as flag with a gpio number from board file.
and just implement stuff related to ehci only like tll reset and ulpi
phy configuration or
hsic mode configuration based on some data passed from board file.
So we can re-use most of ehci-omap.c, I have done a similar approach
as said which
is intending to provide generic ehci-omap.c usage, which I was planning to
re-use for beagle board, But since you are at it already can we make
ehci-omap.c
more generic.
+1
Thanks, Will wait for IIya Yanok's feedback on the approach to be followed
(whether to re-base from this patch or use my series to clean up beagle).
As we are planning to re-use ehci-omap.c for panda and other board support.
Reference to patch done for panda initially.
http://patchwork.ozlabs.org/patch/131362/
One thing that I planning to do in this patch is moving all reg
offsets from asm/ehci.h to
include/asm/arch-omap4/ehci.h and retain only generic stuff in ehci.h
thus we can have offsets from beagle from */arch-omap3/ehci.h and
re-use most code from
ehci-omap.c
board/ti/beagle/beagle.c | 101 --
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-omap.c | 156
include/configs/omap3_beagle.h | 3 +
4 files changed, 160 insertions(+), 101 deletions(-)
create mode 100644 drivers/usb/host/ehci-omap.c
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index 6a457cb..3d63028 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -42,15 +42,6 @@
#include asm/arch/sys_proto.h
#include asm/gpio.h
#include asm/mach-types.h
-#ifdef CONFIG_USB_EHCI
-#include usb.h
-#include asm/arch/clocks.h
-#include asm/arch/clocks_omap3.h
-#include asm/arch/ehci_omap3.h
-/* from drivers/usb/host/ehci-core.h */
-extern struct ehci_hccr *hccr;
-extern volatile struct ehci_hcor *hcor;
-#endif
#include beagle.h
#include command.h
@@ -441,104 +432,12 @@ int board_mmc_init(bd_t *bis)
#endif
#ifdef CONFIG_USB_EHCI
-
-#define GPIO_PHY_RESET 147
-
-/* Reset is needed otherwise the kernel-driver will throw an error. */
-int ehci_hcd_stop(void)
-{
- pr_debug(Resetting OMAP3 EHCI\n);
- gpio_set_value(GPIO_PHY_RESET, 0);
- writel(OMAP_UHH_SYSCONFIG_SOFTRESET, OMAP3_UHH_BASE +
OMAP_UHH_SYSCONFIG);
- /* disable USB clocks */
- struct prcm *prcm_base = (struct prcm *)PRCM_BASE;
- sr32(prcm_base-iclken_usbhost, 0, 1, 0);
- sr32(prcm_base-fclken_usbhost, 0, 2, 0);
- sr32(prcm_base-iclken3_core, 2, 1, 0);
- sr32(prcm_base-fclken3_core, 2, 1, 0);
- return 0;
-}
-
As said above only uhh reset should be done in ehci-omap and
clock and gpio can be left in baird file itslef
you can just implement ehci_omap_hcd_stop that will reset uhh.
Or add SoC specific ehci_clk_disable()
and put the clock handling in it.
probably the right method to do is as we did for panda,
Add to armv7/omap3/clock.c (soc specific code) to enable usb-host clocks.
as done in below patch for omap4 socs.
http://patchwork.ozlabs.org/patch/131365/
/* Call usb_stop() before starting the kernel */
void show_boot_progress(int val)
{
if(val == 15)
usb_stop();
}
-
-/*
- * Initialize the OMAP3 EHCI controller and PHY on the BeagleBoard.
- * Based on drivers/usb/host/ehci-omap.c from Linux 2.6.37.
- * See there for additional Copyrights.
- */
-int ehci_hcd_init(void)
-{
- pr_debug(Initializing OMAP3 ECHI\n);
-
- /* Put the PHY in RESET */
- gpio_request(GPIO_PHY_RESET
Re: [U-Boot] [PATCH V4 1/2] ehci-omap: driver for EHCI host on OMAP3
On Thu, Dec 22, 2011 at 3:29 PM, Igor Grinberg grinb...@compulab.co.il wrote: On 12/22/11 11:26, Govindraj wrote: Hi Igor, [...] probably the right method to do is as we did for panda, Add to armv7/omap3/clock.c (soc specific code) to enable usb-host clocks. as done in below patch for omap4 socs. http://patchwork.ozlabs.org/patch/131365/ Hmmm... I don't like that patch - this is the right method... but only for panda! For panda it makes sense to enable the USB related clocks by default because it has many of its boot important peripherals wired to USB. That is not the case with majority of OMAP3 (and I bet with many other OMAP4) boards. Therefore, I think the USB clocks need to be turned on only if the board requests them to be turned on and not as a part of the default clock initialization by the PRCM subsystem (unless it is configurable in the board config file). okay, I thought nothing wrong in keeping them enabled by default. since all un-used clocks will be gated once kernel is loaded. Am I missing some thing here? so as discussed earlier we can add ehci_omap3_clock_init into ehci-omap.c that can be used from all omap3 socs. -- Thanks, Govindraj.R ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] ehci-omap: driver for EHCI host on OMAP3
On Thu, Dec 22, 2011 at 4:48 PM, Igor Grinberg grinb...@compulab.co.il wrote:
On 12/22/11 12:49, Govindraj wrote:
On Thu, Dec 22, 2011 at 3:29 PM, Igor Grinberg grinb...@compulab.co.il
wrote:
On 12/22/11 11:26, Govindraj wrote:
Hi Igor,
[...]
probably the right method to do is as we did for panda,
Add to armv7/omap3/clock.c (soc specific code) to enable usb-host clocks.
as done in below patch for omap4 socs.
http://patchwork.ozlabs.org/patch/131365/
Hmmm... I don't like that patch - this is the right method...
but only for panda!
For panda it makes sense to enable the USB related clocks by default
because it has many of its boot important peripherals wired to USB.
That is not the case with majority of OMAP3 (and I bet with many
other OMAP4) boards.
Therefore, I think the USB clocks need to be turned on
only if the board requests them to be turned on and not as a part
of the default clock initialization by the PRCM subsystem
(unless it is configurable in the board config file).
okay, I thought nothing wrong in keeping them enabled by default.
since all un-used clocks will be gated once kernel is loaded.
Am I missing some thing here?
May be there is nothing *too* wrong except for power consumption or
may be some other things I can't think of right now...
But, you should not rely on what will happen when kernel is loaded.
Also, you should not assume, that the Linux kernel will be loaded at all...
There are other OSes around that can also use U-Boot as a boot loader.
Also, there are stand alone applications that do not use any OS at all...
We are in the embedded world also, not just mobile...
(And if we are talking about mobile, then power consumption is important).
Yes Agree..
so as discussed earlier we can add ehci_omap3_clock_init
into ehci-omap.c that can be used from all omap3 socs.
This is a bit confusing...
Let's try it that way:
1) ehci-omap.c should have common OMAP (OMAP3/4/5...) settings
2) ehci-omap.c should call ehci_clk_{enable|disable}() which should
be implemented in a SoC *dependent* way (e.g. armv7/omap{3|4}/clock.c)
3) board specific stuff (e.g. PHY reset GPIO) should be passed
to the common code to avoid code duplication.
4) probably, some other things that I've forgotten...
Looks fine.
I will start on the above discussed stuff on top of this patch.
--
Thanks,
Govindraj.R
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] ehci-omap: driver for EHCI host on OMAP3
Hi IIya Yanok,
Sorry for late comments.
On Tue, Dec 13, 2011 at 4:45 AM, Ilya Yanok ya...@emcraft.com wrote:
Taken from Beagle code. Tested on mcx board (AM3517-based).
Signed-off-by: Ilya Yanok ya...@emcraft.com
---
Changes from V3:
- None
Changes from V2:
- None
Changes from V1:
- CONFIG_OMAP_EHCI_PHYx_RESET changed to CONFIG_OMAP_EHCI_PHYx_RESET_GPIO
- phy reset moved to separate function
- Calls to gpio_set_value after gpio_direction_output removed
Here I see lot of stuff are just being moved from beagle board to new file
ehci-omap.c , but echi-omap.c is not generic enough for re-use
I think we should maintain clock handling and any gpio reset in board
file itself
and just implement stuff related to ehci only like tll reset and ulpi
phy configuration or
hsic mode configuration based on some data passed from board file.
So we can re-use most of ehci-omap.c, I have done a similar approach
as said which
is intending to provide generic ehci-omap.c usage, which I was planning to
re-use for beagle board, But since you are at it already can we make ehci-omap.c
more generic.
As we are planning to re-use ehci-omap.c for panda and other board support.
Reference to patch done for panda initially.
http://patchwork.ozlabs.org/patch/131362/
One thing that I planning to do in this patch is moving all reg
offsets from asm/ehci.h to
include/asm/arch-omap4/ehci.h and retain only generic stuff in ehci.h
thus we can have offsets from beagle from */arch-omap3/ehci.h and
re-use most code from
ehci-omap.c
board/ti/beagle/beagle.c | 101 --
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-omap.c | 156
include/configs/omap3_beagle.h | 3 +
4 files changed, 160 insertions(+), 101 deletions(-)
create mode 100644 drivers/usb/host/ehci-omap.c
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index 6a457cb..3d63028 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -42,15 +42,6 @@
#include asm/arch/sys_proto.h
#include asm/gpio.h
#include asm/mach-types.h
-#ifdef CONFIG_USB_EHCI
-#include usb.h
-#include asm/arch/clocks.h
-#include asm/arch/clocks_omap3.h
-#include asm/arch/ehci_omap3.h
-/* from drivers/usb/host/ehci-core.h */
-extern struct ehci_hccr *hccr;
-extern volatile struct ehci_hcor *hcor;
-#endif
#include beagle.h
#include command.h
@@ -441,104 +432,12 @@ int board_mmc_init(bd_t *bis)
#endif
#ifdef CONFIG_USB_EHCI
-
-#define GPIO_PHY_RESET 147
-
-/* Reset is needed otherwise the kernel-driver will throw an error. */
-int ehci_hcd_stop(void)
-{
- pr_debug(Resetting OMAP3 EHCI\n);
- gpio_set_value(GPIO_PHY_RESET, 0);
- writel(OMAP_UHH_SYSCONFIG_SOFTRESET, OMAP3_UHH_BASE +
OMAP_UHH_SYSCONFIG);
- /* disable USB clocks */
- struct prcm *prcm_base = (struct prcm *)PRCM_BASE;
- sr32(prcm_base-iclken_usbhost, 0, 1, 0);
- sr32(prcm_base-fclken_usbhost, 0, 2, 0);
- sr32(prcm_base-iclken3_core, 2, 1, 0);
- sr32(prcm_base-fclken3_core, 2, 1, 0);
- return 0;
-}
-
As said above only uhh reset should be done in ehci-omap and
clock and gpio can be left in baird file itslef
you can just implement ehci_omap_hcd_stop that will reset uhh.
/* Call usb_stop() before starting the kernel */
void show_boot_progress(int val)
{
if(val == 15)
usb_stop();
}
-
-/*
- * Initialize the OMAP3 EHCI controller and PHY on the BeagleBoard.
- * Based on drivers/usb/host/ehci-omap.c from Linux 2.6.37.
- * See there for additional Copyrights.
- */
-int ehci_hcd_init(void)
-{
- pr_debug(Initializing OMAP3 ECHI\n);
-
- /* Put the PHY in RESET */
- gpio_request(GPIO_PHY_RESET, );
- gpio_direction_output(GPIO_PHY_RESET, 0);
- gpio_set_value(GPIO_PHY_RESET, 0);
-
- /* Hold the PHY in RESET for enough time till DIR is high */
- /* Refer: ISSUE1 */
- udelay(10);
-
- struct prcm *prcm_base = (struct prcm *)PRCM_BASE;
- /* Enable USBHOST_L3_ICLK (USBHOST_MICLK) */
- sr32(prcm_base-iclken_usbhost, 0, 1, 1);
- /*
- * Enable USBHOST_48M_FCLK (USBHOST_FCLK1)
- * and USBHOST_120M_FCLK (USBHOST_FCLK2)
- */
- sr32(prcm_base-fclken_usbhost, 0, 2, 3);
- /* Enable USBTTL_ICLK */
- sr32(prcm_base-iclken3_core, 2, 1, 1);
- /* Enable USBTTL_FCLK */
- sr32(prcm_base-fclken3_core, 2, 1, 1);
- pr_debug(USB clocks enabled\n);
-
same here also must be left in beagle board file and
implement omap_ehci_hcd_init() which will reset uhh, tll and
configure phy_ulpi mode.
- /* perform TLL soft reset, and wait until reset is complete */
- writel(OMAP_USBTLL_SYSCONFIG_SOFTRESET,
- OMAP3_USBTLL_BASE + OMAP_USBTLL_SYSCONFIG);
- /* Wait for TLL reset to complete */
- while
Re: [U-Boot] [PATCH 1/6] omap4: usb: Add omap-ehci support
Hi Tom,
On Wed, Dec 14, 2011 at 9:30 PM, Tom Rini tom.r...@gmail.com wrote:
On Wed, Dec 14, 2011 at 5:09 AM, Govindraj.R govindraj.r...@ti.com wrote:
From: Govindraj.R govindraj.r...@ti.com
[snip]
+/* TLL Register Set */
+#define OMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 3)
Globally, please fix all #definetab to #definespace.
+#define OMAP_USBTLL_SYSCONFIG_AUTOIDLE (1 0)
+#define OMAP_USBTLL_SYSSTATUS_RESETDONE (1 0)
Just use '1' not '(1 0)', globally.
[snip]
+++ b/drivers/usb/host/ehci-omap.c
[snip]
+ reg = ULPI_FUNC_CTRL_RESET
+ /* FUNCTION_CTRL_SET register */
+ | (ULPI_SET(ULPI_FUNC_CTRL)
EHCI_INSNREG05_ULPI_REGADD_SHIFT)
+ /* Write */
+ | (2 EHCI_INSNREG05_ULPI_OPSEL_SHIFT)
+ /* PORTn */
+ | ((port + 1) EHCI_INSNREG05_ULPI_PORTSEL_SHIFT)
+ /* start ULPI access*/
+ | (1 EHCI_INSNREG05_ULPI_CONTROL_SHIFT);
Can you please re-write this as:
/*
* What these values are doing...
*/
reg = A | (B B_SHIFT) | ...
[snip]
+ /* Wait for ULPI access completion */
+ while ((readl(ehci-insreg05_utmi_ulpi)
+ (1 EHCI_INSNREG05_ULPI_CONTROL_SHIFT)))
+ if (get_timer(init) CONFIG_SYS_HZ) {
Perhaps gmail is getting the indentation wrong here but it seems not
right and the norm is to not start the newline with '' or '|' or
similar.
Thanks for the comments will fix and re-post a new version.
[snip]
+ /*
+ * An undocumented feature in the OMAP3 EHCI controller,
+ * causes suspended ports to be taken out of suspend when
+ * the USBCMD.Run/Stop bit is cleared (for example when
+ * we do ehci_bus_suspend).
+ * This breaks suspend-resume if the root-hub is allowed
+ * to suspend. Writing 1 to this undocumented register bit
+ * disables this feature and restores normal behavior.
+ */
Thank you for clearly commenting on an undocumented feature!
Even 'tho there's changes requested already I've moved this to Remy in
patchwork because I want his comments as the USB maintainer as well.
Thanks!
Yes fine, I will CC him the next version,
in case if there are no comments until I post v2.
--
Thanks,
Govindraj.R
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] OMAP4: config: Add usb support for panda config.
On Wed, Dec 14, 2011 at 9:54 PM, Tom Rini tom.r...@gmail.com wrote: On Wed, Dec 14, 2011 at 5:21 AM, Govindraj.R govindraj...@gmail.com wrote: From: Govindraj.R govindraj.r...@ti.com Enable usb ehci support and Ethernet support for panda board. Disable dcache as usb uses dma operations and to avoid any resulting cache coherency issue. Signed-off-by: Govindraj.R govindraj.r...@ti.com I'm not thrilled with disabling dcache globally for this. We can just do 'dcache off' and then start doing USB ops, or since this won't get in until 2012.03, can we spend more time making USB cache coherent? --- include/configs/omap4_common.h | 1 + include/configs/omap4_panda.h | 21 + 2 files changed, 22 insertions(+), 0 deletions(-) diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h index a989721..43a98f9 100644 --- a/include/configs/omap4_common.h +++ b/include/configs/omap4_common.h @@ -152,6 +152,7 @@ loadaddr=0x8200\0 \ console=ttyO2,115200n8\0 \ usbtty=cdc_acm\0 \ + usbethaddr=00:02:03:04:05:06\0 \ vram=16M\0 \ mmcdev=0\0 \ mmcroot=/dev/mmcblk0p2 rw\0 \ Just like you can't hard-code ethaddr into config files, I'm pretty sure you can't do that for usbethaddr. I think this can be set even in the command line will check the options and do the changes as required. diff --git a/include/configs/omap4_panda.h b/include/configs/omap4_panda.h index e9ef2a3..1475012 100644 --- a/include/configs/omap4_panda.h +++ b/include/configs/omap4_panda.h @@ -33,7 +33,28 @@ */ #define CONFIG_PANDA 1 /* working with Panda */ +#define CONFIG_SYS_DCACHE_OFF 1 + +/* USB UHH support options */ +#define CONFIG_CMD_USB 1 +#define CONFIG_USB_HOST 1 +#define CONFIG_USB_EHCI 1 +#define CONFIG_USB_EHCI_OMAP 1 +#define CONFIG_USB_STORAGE 1 +#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3 Just '#define CONFIG_CMD_USB' okay fine. (and if you want to do a separate pre-patch cleaning up the existing config files I'd appreciate it). Sure. +/* USB Networking options */ +#define CONFIG_USB_HOST_ETHER 1 +#define CONFIG_USB_ETHER_SMSC95XX 1 + +#define CONFIG_UBOOT_ENABLE_PADS_ALL 1 + +#define CONFIG_NET_MULTI 1 CONFIG_NET_MULTI went away. my bad I missed that. Will clean up. -- Thanks, Govindraj.R ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] OMAP4: config: Add usb support for panda config.
On Wed, Dec 14, 2011 at 9:57 PM, Tom Rini tom.r...@gmail.com wrote: On Wed, Dec 14, 2011 at 9:24 AM, Tom Rini tom.r...@gmail.com wrote: On Wed, Dec 14, 2011 at 5:21 AM, Govindraj.R govindraj...@gmail.com wrote: From: Govindraj.R govindraj.r...@ti.com Enable usb ehci support and Ethernet support for panda board. Disable dcache as usb uses dma operations and to avoid any resulting cache coherency issue. Signed-off-by: Govindraj.R govindraj.r...@ti.com I'm not thrilled with disabling dcache globally for this. We can just do 'dcache off' and then start doing USB ops, or since this won't get in until 2012.03, can we spend more time making USB cache coherent? Oh, and I'd really like to see add USB support to panda, enable it in config as one commit. Yes sure. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] OMAP4: config: Add usb support for panda config.
On Wed, Dec 14, 2011 at 9:54 PM, Tom Rini tom.r...@gmail.com wrote: On Wed, Dec 14, 2011 at 5:21 AM, Govindraj.R govindraj...@gmail.com wrote: From: Govindraj.R govindraj.r...@ti.com Enable usb ehci support and Ethernet support for panda board. Disable dcache as usb uses dma operations and to avoid any resulting cache coherency issue. Yes will check the options. -- Thanks, Govindraj.R ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] omap4: usb: Add omap-ehci support
Hi Chris, On Wed, Dec 14, 2011 at 7:08 PM, Chris Lalancette clalance...@gmail.com wrote: On Wed, Dec 14, 2011 at 7:09 AM, Govindraj.R govindraj.r...@ti.com wrote: From: Govindraj.R govindraj.r...@ti.com Adds ehci-omap and two funcs omap_ehci_hcd_init/omap_ehci_hcd_stop Which can be called from any board file implementing the ehci_hcd_init/reset. One can pass the port modes from board file and configure the usb host to ulpi-phy mode or hsic mode. Signed-off-by: Govindraj.R govindraj.r...@ti.com --- arch/arm/include/asm/ehci-omap.h | 168 +++ drivers/usb/host/Makefile | 1 + drivers/usb/host/ehci-omap.c | 202 ++ 3 files changed, 371 insertions(+), 0 deletions(-) create mode 100644 arch/arm/include/asm/ehci-omap.h create mode 100644 drivers/usb/host/ehci-omap.c diff --git a/arch/arm/include/asm/ehci-omap.h b/arch/arm/include/asm/ehci-omap.h new file mode 100644 index 000..c1af798 --- /dev/null +++ b/arch/arm/include/asm/ehci-omap.h @@ -0,0 +1,168 @@ ... +/* Alt CLK SRC FOR AUX CLK 3 to USB3220C external PHY */ +#define SCRM_ALTCLKSRC 0x4a30A110UL +#define SCRM_AUXCLK3 0x4A30A31CUL I'll just point out here that the patch I recently posted to enable the USB hub on panda (http://lists.denx.de/pipermail/u-boot/2011-December/113194.html) adds an scrm structure that also has these registers. Depending on which order the patches go in, you might want to re-use that. Yes I have used your patch. (Refer to cover letter added this series depends on your patch http://www.mail-archive.com/u-boot@lists.denx.de/msg72797.html ) But during cleanup forgot to remove from the header file. Will remove this, Thanks for pointing this out. -- Regards, Govindraj.R ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
