[U-Boot] Please pull u-boot-ti/master
Hello,
The following changes since commit 3da0e5750b24a9491058df6126c7be577a276c09:
arm: factorize relocate_code routine (2013-05-30 20:24:38 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-ti.git master
for you to fetch changes up to 80dd596d1b442ff53dbeb33eccdb8efd2283be79:
arm: da830: moved pinmux configurations to the arch tree (2013-06-07 14:26:08 -0400)
---------------------------------------------------------------- Andrii Tseglytskyi (2): OMAP3+: introduce generic ABB support OMAP5: add ABB setup for MPU voltage domain
Balaji T K (1): mmc: omap_hsmmc: Update pbias programming
Joel A Fernandes (1): am33xx: Board: Make CPSW section of ethernet initialization depend on CPSW driver
Lokesh Vutla (10): ARM: OMAP4+: Cleanup header files ARM: OMAP2+: Rename asm/arch/clocks.h asm/arch/clock.h ARM: OMAP4+: pmic: Make generic bus init and write functions ARM: DRA7xx: Add control id code for DRA7xx ARM: DRA7xx: power Add support for tps659038 PMIC ARM: DRA7xx: clocks: Fixing i2c_init for PMIC ARM: DRA7xx: Do not enable srcomp for DRA7xx Soc's ARM: DRA7xx: Update pinmux data ARM: DRA7xx: clocks: Update PLL values ARM: DRA7: Add Maintainer
Lubomir Popov (4): OMAP5: Fix bug in omap5_es1_prcm struct ARM: OMAP5: Power: Add more functionality to Palmas driver ARM: OMAP: I2C: New read, write and probe functions OMAP5: Enable access to auxclk registers
Michael Trimarchi (1): usb: omap: ulpi: fix ulpi transceiver access
Nishanth Menon (1): ARM: OMAP5: DRA7xx: support class 0 optimized voltages
Sricharan R (5): ARM: OMAP5: clocks: Do not enable sgx clocks ARM: DRA7xx: Change the Debug UART to UART1 ARM: DRA7xx: Correct the SYS_CLK to 20MHZ ARM: DRA7xx: Correct SRAM END address ARM: DRA7xx: EMIF: Change settings required for EVM board
Tom Rini (4): omap-common/hwinit-common.c: Mark omap_rev_string as static am33xx: Correct NON_SECURE_SRAM_START/END am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.c arm: Remove OMAP2420H4 and all omap24xx support
Vishwanathrao Badarkhe, Manish (2): da830: add MMC support arm: da830: moved pinmux configurations to the arch tree
MAINTAINERS | 8 +- arch/arm/cpu/arm1136/start.S | 18 - arch/arm/cpu/arm926ejs/davinci/Makefile | 1 + arch/arm/cpu/arm926ejs/davinci/da830_pinmux.c | 151 ++++ arch/arm/cpu/armv7/omap-common/Makefile | 1 + arch/arm/cpu/armv7/omap-common/abb.c | 137 ++++ arch/arm/cpu/armv7/omap-common/boot-common.c | 39 + arch/arm/cpu/armv7/omap-common/clocks-common.c | 101 ++- arch/arm/cpu/armv7/omap-common/emif-common.c | 28 +- arch/arm/cpu/armv7/omap-common/hwinit-common.c | 40 +- arch/arm/cpu/armv7/omap-common/timer.c | 1 + arch/arm/cpu/armv7/omap-common/vc.c | 14 +- arch/arm/cpu/armv7/omap3/clock.c | 2 +- arch/arm/cpu/armv7/omap4/hw_data.c | 13 +- arch/arm/cpu/armv7/omap4/prcm-regs.c | 3 + arch/arm/cpu/armv7/omap5/Makefile | 1 + arch/arm/cpu/armv7/omap5/abb.c | 67 ++ arch/arm/cpu/armv7/omap5/hw_data.c | 167 ++-- arch/arm/cpu/armv7/omap5/hwinit.c | 24 +- arch/arm/cpu/armv7/omap5/prcm-regs.c | 20 + arch/arm/cpu/armv7/omap5/sdram.c | 170 +++- arch/arm/include/asm/arch-am33xx/omap.h | 4 +- arch/arm/include/asm/arch-am33xx/sys_proto.h | 1 + arch/arm/include/asm/arch-davinci/pinmux_defs.h | 15 +- arch/arm/include/asm/arch-omap24xx/bits.h | 48 -- arch/arm/include/asm/arch-omap24xx/clocks.h | 112 --- arch/arm/include/asm/arch-omap24xx/i2c.h | 68 -- arch/arm/include/asm/arch-omap24xx/mem.h | 156 ---- arch/arm/include/asm/arch-omap24xx/mux.h | 176 ---- arch/arm/include/asm/arch-omap24xx/omap2420.h | 236 ------ arch/arm/include/asm/arch-omap24xx/sys_info.h | 82 -- arch/arm/include/asm/arch-omap24xx/sys_proto.h | 54 -- .../include/asm/arch-omap3/{clocks.h => clock.h} | 0 arch/arm/include/asm/arch-omap3/omap3.h | 7 + .../include/asm/arch-omap4/{clocks.h => clock.h} | 34 +- arch/arm/include/asm/arch-omap4/cpu.h | 12 - arch/arm/include/asm/arch-omap4/omap.h | 22 +- arch/arm/include/asm/arch-omap4/sys_proto.h | 6 +- .../include/asm/arch-omap5/{clocks.h => clock.h} | 91 +- arch/arm/include/asm/arch-omap5/cpu.h | 12 - arch/arm/include/asm/arch-omap5/mux_dra7xx.h | 7 +- arch/arm/include/asm/arch-omap5/omap.h | 67 +- arch/arm/include/asm/arch-omap5/sys_proto.h | 8 +- arch/arm/include/asm/emif.h | 12 +- arch/arm/include/asm/omap_common.h | 59 +- arch/arm/lib/cache.c | 2 +- board/davinci/da8xxevm/da830evm.c | 155 +--- board/htkw/mcx/mcx.c | 2 +- board/isee/igep0033/board.c | 9 + board/phytec/pcm051/board.c | 9 + board/teejet/mt_ventoux/mt_ventoux.c | 2 +- board/ti/am335x/board.c | 11 + board/ti/dra7xx/mux_data.h | 38 +- board/ti/omap2420h4/Makefile | 45 - board/ti/omap2420h4/config.mk | 28 - board/ti/omap2420h4/lowlevel_init.S | 185 ----- board/ti/omap2420h4/mem.c | 362 -------- board/ti/omap2420h4/omap2420h4.c | 867 -------------------- board/ti/omap2420h4/sys_info.c | 387 --------- board/ti/omap5_uevm/evm.c | 12 +- board/ti/panda/panda.c | 22 +- board/ti/sdp4430/sdp.c | 16 +- board/ti/ti814x/evm.c | 9 + boards.cfg | 2 - doc/README.scrapyard | 1 + drivers/i2c/omap24xx_i2c.c | 490 ++++++----- drivers/mmc/omap_hsmmc.c | 20 +- drivers/power/palmas.c | 133 ++- drivers/serial/ns16550.c | 5 - drivers/serial/serial_ns16550.c | 5 - drivers/usb/musb/omap3.c | 4 +- drivers/usb/ulpi/omap-ulpi-viewport.c | 40 +- include/configs/am335x_evm.h | 10 +- include/configs/da830evm.h | 25 +- include/configs/dra7xx_evm.h | 8 +- include/configs/igep0033.h | 10 +- include/configs/omap2420h4.h | 264 ------ include/configs/omap4_common.h | 4 - include/configs/omap5_common.h | 12 +- include/configs/omap5_uevm.h | 7 +- include/configs/pcm051.h | 10 +- include/palmas.h | 90 +- 82 files changed, 1792 insertions(+), 3804 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/davinci/da830_pinmux.c create mode 100644 arch/arm/cpu/armv7/omap-common/abb.c create mode 100644 arch/arm/cpu/armv7/omap5/abb.c delete mode 100644 arch/arm/include/asm/arch-omap24xx/bits.h delete mode 100644 arch/arm/include/asm/arch-omap24xx/clocks.h delete mode 100644 arch/arm/include/asm/arch-omap24xx/i2c.h delete mode 100644 arch/arm/include/asm/arch-omap24xx/mem.h delete mode 100644 arch/arm/include/asm/arch-omap24xx/mux.h delete mode 100644 arch/arm/include/asm/arch-omap24xx/omap2420.h delete mode 100644 arch/arm/include/asm/arch-omap24xx/sys_info.h delete mode 100644 arch/arm/include/asm/arch-omap24xx/sys_proto.h rename arch/arm/include/asm/arch-omap3/{clocks.h => clock.h} (100%) rename arch/arm/include/asm/arch-omap4/{clocks.h => clock.h} (90%) rename arch/arm/include/asm/arch-omap5/{clocks.h => clock.h} (73%) delete mode 100644 board/ti/omap2420h4/Makefile delete mode 100644 board/ti/omap2420h4/config.mk delete mode 100644 board/ti/omap2420h4/lowlevel_init.S delete mode 100644 board/ti/omap2420h4/mem.c delete mode 100644 board/ti/omap2420h4/omap2420h4.c delete mode 100644 board/ti/omap2420h4/sys_info.c delete mode 100644 include/configs/omap2420h4.h
Hi Tom, Michael,
Hello,
The following changes since commit 3da0e5750b24a9491058df6126c7be577a276c09:
arm: factorize relocate_code routine (2013-05-30 20:24:38 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-ti.git master
for you to fetch changes up to 80dd596d1b442ff53dbeb33eccdb8efd2283be79:
[snip]
Michael Trimarchi (1): usb: omap: ulpi: fix ulpi transceiver access
[snip]
drivers/usb/ulpi/omap-ulpi-viewport.c | 40 +-
[snip]
I just made a clean clone of u-boot-ti/master, manually applied the changes to the ehci files, added my board files and made a build. Everything seems to work fine, but I see an error message regarding ULPI reset that was not present before, and obviously it is due to Michael's changes:
SOM5_EVB # usb start (Re)start USB... USB0: ULPI: ulpi_reset: failed writing reset bit USB EHCI 1.00 scanning bus 0 for devices... 6 USB Device(s) found scanning usb for storage devices... 3 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found SOM5_EVB # usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Mass Storage (480 Mb/s, 200mA) | FSC MEMORYBIRD USB2 C157040817120315AA | +-3 Hub (480 Mb/s, 2mA) | | | +-4 Mass Storage (480 Mb/s, 96mA) | | Generic Ultra Fast Media Reader 000000264001 | | | +-5 Mass Storage (480 Mb/s, 100mA) | USB Flash Drive 531C43B21928F11F | +-6 Vendor specific (480 Mb/s, 500mA)
SOM5_EVB #
Otherwise everything is OK, the device on the ULPI port is working (it is #2 above). It is now late and I shall investigate in detail tomorrow, this is just an early warning ;)
Best regards, Lubo
Hi Lubomir,
On 06/08/13 23:43, Lubomir Popov wrote:
Hi Tom, Michael,
Hello,
The following changes since commit 3da0e5750b24a9491058df6126c7be577a276c09:
arm: factorize relocate_code routine (2013-05-30 20:24:38 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-ti.git master
for you to fetch changes up to 80dd596d1b442ff53dbeb33eccdb8efd2283be79:
[snip]
Michael Trimarchi (1): usb: omap: ulpi: fix ulpi transceiver access
[snip]
drivers/usb/ulpi/omap-ulpi-viewport.c | 40 +-
[snip]
I just made a clean clone of u-boot-ti/master, manually applied the changes to the ehci files, added my board files and made a build. Everything seems to work fine, but I see an error message regarding ULPI reset that was not present before, and obviously it is due to Michael's changes:
Yes indeed, those are due to Michael's patch. Michael's patch aligns the code with the TRM and seems to reveal an OMAP USB bug might an erratum.
SOM5_EVB # usb start (Re)start USB... USB0: ULPI: ulpi_reset: failed writing reset bit USB EHCI 1.00 scanning bus 0 for devices... 6 USB Device(s) found scanning usb for storage devices... 3 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found SOM5_EVB # usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Mass Storage (480 Mb/s, 200mA) | FSC MEMORYBIRD USB2 C157040817120315AA | +-3 Hub (480 Mb/s, 2mA) | | | +-4 Mass Storage (480 Mb/s, 96mA) | | Generic Ultra Fast Media Reader 000000264001 | | | +-5 Mass Storage (480 Mb/s, 100mA) | USB Flash Drive 531C43B21928F11F | +-6 Vendor specific (480 Mb/s, 500mA)
SOM5_EVB #
Otherwise everything is OK, the device on the ULPI port is working (it is #2 above). It is now late and I shall investigate in detail tomorrow, this is just an early warning ;)
Best regards, Lubo
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Hi
On 06/08/2013 10:43 PM, Lubomir Popov wrote:
Hi Tom, Michael,
Hello,
The following changes since commit 3da0e5750b24a9491058df6126c7be577a276c09:
arm: factorize relocate_code routine (2013-05-30 20:24:38 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-ti.git master
for you to fetch changes up to 80dd596d1b442ff53dbeb33eccdb8efd2283be79:
[snip]
Michael Trimarchi (1): usb: omap: ulpi: fix ulpi transceiver access
[snip]
drivers/usb/ulpi/omap-ulpi-viewport.c | 40 +-
[snip]
I just made a clean clone of u-boot-ti/master, manually applied the changes to the ehci files, added my board files and made a build. Everything seems to work fine, but I see an error message regarding ULPI reset that was not present before, and obviously it is due to Michael's changes:
SOM5_EVB # usb start (Re)start USB... USB0: ULPI: ulpi_reset: failed writing reset bit
Let me understand. The patch is wrong because you have a problem now. The old code was not sending any write command so any ulpi_reset and the test condition was wrong.
USB EHCI 1.00 scanning bus 0 for devices... 6 USB Device(s) found scanning usb for storage devices... 3 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found SOM5_EVB # usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Mass Storage (480 Mb/s, 200mA) | FSC MEMORYBIRD USB2 C157040817120315AA | +-3 Hub (480 Mb/s, 2mA) | | | +-4 Mass Storage (480 Mb/s, 96mA) | | Generic Ultra Fast Media Reader 000000264001 | | | +-5 Mass Storage (480 Mb/s, 100mA) | USB Flash Drive 531C43B21928F11F | +-6 Vendor specific (480 Mb/s, 500mA)
SOM5_EVB #
Otherwise everything is OK, the device on the ULPI port is working (it is #2 above). It is now late and I shall investigate in detail tomorrow, this is just an early warning ;)
Can you test the attach patch? Yes I know it is not inline but I will send inline tomorrow and I have done changing the old one. I was thinking port number was starting from 1 but I have done a quick check on soft_reset of omap and it is starting from 0
Michael
Best regards, Lubo
Hi Michael,
On 10/06/13 00:37, Michael Trimarchi wrote:
Hi
On 06/08/2013 10:43 PM, Lubomir Popov wrote:
Hi Tom, Michael,
Hello,
The following changes since commit 3da0e5750b24a9491058df6126c7be577a276c09:
arm: factorize relocate_code routine (2013-05-30 20:24:38 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-ti.git master
for you to fetch changes up to 80dd596d1b442ff53dbeb33eccdb8efd2283be79:
[snip]
Michael Trimarchi (1): usb: omap: ulpi: fix ulpi transceiver access
[snip]
drivers/usb/ulpi/omap-ulpi-viewport.c | 40 +-
[snip]
I just made a clean clone of u-boot-ti/master, manually applied the changes to the ehci files, added my board files and made a build. Everything seems to work fine, but I see an error message regarding ULPI reset that was not present before, and obviously it is due to Michael's changes:
SOM5_EVB # usb start (Re)start USB... USB0: ULPI: ulpi_reset: failed writing reset bit
Let me understand. The patch is wrong because you have a problem now. The old code was not sending any write command so any ulpi_reset and the test condition was wrong.
Right.
USB EHCI 1.00 scanning bus 0 for devices... 6 USB Device(s) found scanning usb for storage devices... 3 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found SOM5_EVB # usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Mass Storage (480 Mb/s, 200mA) | FSC MEMORYBIRD USB2 C157040817120315AA | +-3 Hub (480 Mb/s, 2mA) | | | +-4 Mass Storage (480 Mb/s, 96mA) | | Generic Ultra Fast Media Reader 000000264001 | | | +-5 Mass Storage (480 Mb/s, 100mA) | USB Flash Drive 531C43B21928F11F | +-6 Vendor specific (480 Mb/s, 500mA)
SOM5_EVB #
Otherwise everything is OK, the device on the ULPI port is working (it is #2 above). It is now late and I shall investigate in detail tomorrow, this is just an early warning ;)
Can you test the attach patch? Yes I know it is not inline but I will send inline tomorrow and I have done changing the old one. I was thinking port number was starting from 1 but I have done a quick check on soft_reset of omap and it is starting from 0
Just tested on a OMAP5430 custom board. Everything is OK, PHY soft reset passes. My ULPI PHY is on port 0, and with the previous version the insreg05 bit 31 remained stuck at 1, producing this error. Now when we write 1 to the port field instead of 0, everything is fine. So
Tested-by: Lubomir Popov lpopov@mm-sol.com
While testing, I however encountered another issue (not related to this patch, take it easy ;-) ): one particular USB flash stick, connected to the ULPI port, does systematically (100%) not get detected upon the first 'usb start' command after power-on; subsequent usb start/reset commands detect it alright. I have experimented a bit with some delays (assuming that it is some sort of timing problem), but without success. Other sticks are OK. Removing the call to omap_ehci_soft_phy_reset() (which calls ulpi_reset() and the viewport stuff) does not change anything.
I'm currently at work, where I have other obligations and cannot spend much time for U-Boot. Therefore, if somebody could share any experience on this subject, please let me know.
One thing that perhaps I should clarify: my ULPI PHY is the TI part TUSB1210; on the other hand, TI themselves recommend PHYs by SMSC, at least for the OMAP4. This was not the case for OMAP5, but who knows...
Thanks, Lubo
Michael
Best regards, Lubo
Hi
On Mon, Jun 10, 2013 at 11:54:31AM +0300, Lubomir Popov wrote:
Hi Michael,
On 10/06/13 00:37, Michael Trimarchi wrote:
Hi
On 06/08/2013 10:43 PM, Lubomir Popov wrote:
Hi Tom, Michael,
Hello,
The following changes since commit 3da0e5750b24a9491058df6126c7be577a276c09:
arm: factorize relocate_code routine (2013-05-30 20:24:38 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-ti.git master
for you to fetch changes up to 80dd596d1b442ff53dbeb33eccdb8efd2283be79:
[snip]
Michael Trimarchi (1): usb: omap: ulpi: fix ulpi transceiver access
[snip]
drivers/usb/ulpi/omap-ulpi-viewport.c | 40 +-
[snip]
I just made a clean clone of u-boot-ti/master, manually applied the changes to the ehci files, added my board files and made a build. Everything seems to work fine, but I see an error message regarding ULPI reset that was not present before, and obviously it is due to Michael's changes:
SOM5_EVB # usb start (Re)start USB... USB0: ULPI: ulpi_reset: failed writing reset bit
Let me understand. The patch is wrong because you have a problem now. The old code was not sending any write command so any ulpi_reset and the test condition was wrong.
Right.
USB EHCI 1.00 scanning bus 0 for devices... 6 USB Device(s) found scanning usb for storage devices... 3 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found SOM5_EVB # usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Mass Storage (480 Mb/s, 200mA) | FSC MEMORYBIRD USB2 C157040817120315AA | +-3 Hub (480 Mb/s, 2mA) | | | +-4 Mass Storage (480 Mb/s, 96mA) | | Generic Ultra Fast Media Reader 000000264001 | | | +-5 Mass Storage (480 Mb/s, 100mA) | USB Flash Drive 531C43B21928F11F | +-6 Vendor specific (480 Mb/s, 500mA)
SOM5_EVB #
Otherwise everything is OK, the device on the ULPI port is working (it is #2 above). It is now late and I shall investigate in detail tomorrow, this is just an early warning ;)
Can you test the attach patch? Yes I know it is not inline but I will send inline tomorrow and I have done changing the old one. I was thinking port number was starting from 1 but I have done a quick check on soft_reset of omap and it is starting from 0
Just tested on a OMAP5430 custom board. Everything is OK, PHY soft reset passes. My ULPI PHY is on port 0, and with the previous version the insreg05 bit 31 remained stuck at 1, producing this error. Now when we write 1 to the port field instead of 0, everything is fine. So
Tested-by: Lubomir Popov lpopov@mm-sol.com
While testing, I however encountered another issue (not related to this patch, take it easy ;-) ): one particular USB flash stick, connected to the ULPI port, does systematically (100%) not get detected upon the first 'usb start' command after power-on; subsequent usb start/reset commands detect it alright. I have experimented a bit with some delays (assuming that it is some sort of timing problem), but without success. Other sticks are OK. Removing the call to omap_ehci_soft_phy_reset() (which calls ulpi_reset() and the viewport stuff) does not change anything.
I'm currently at work, where I have other obligations and cannot spend much time for U-Boot. Therefore, if somebody could share any experience on this subject, please let me know.
One thing that perhaps I should clarify: my ULPI PHY is the TI part TUSB1210; on the other hand, TI themselves recommend PHYs by SMSC, at least for the OMAP4. This was not the case for OMAP5, but who knows...
Thanks, Lubo
Michael
Best regards, Lubo
This patch fix the omap access to the transceiver configuration registers using the ulpi bus. As reported by the documentation the bit31 is used only to check if the transaction is done or still running and the reading and writing operation have different offset and have different values. What we need to do at the end of a transaction is leave the bus in done state. Anyway an error using the ulpi omap register is not recoverable so any error give out the usage of this interface.
Signed-off-by: Michael Trimarchi michael@amarulasolutions.com --- - changes for V4 * port_num start from 0 so we need to take in account when we use the omap access function. * Fix the read function - changes for V3 Fix patch subject - changes for V2 Fix commit message --- drivers/usb/ulpi/omap-ulpi-viewport.c | 42 +++++++-------------------------- 1 file changed, 9 insertions(+), 33 deletions(-)
diff --git a/drivers/usb/ulpi/omap-ulpi-viewport.c b/drivers/usb/ulpi/omap-ulpi-viewport.c index 3c1ea1a..4db7fa4 100644 --- a/drivers/usb/ulpi/omap-ulpi-viewport.c +++ b/drivers/usb/ulpi/omap-ulpi-viewport.c @@ -22,18 +22,19 @@ #include <asm/io.h> #include <usb/ulpi.h>
-#define OMAP_ULPI_WR_OPSEL (3 << 21) -#define OMAP_ULPI_ACCESS (1 << 31) +#define OMAP_ULPI_WR_OPSEL (2 << 22) +#define OMAP_ULPI_RD_OPSEL (3 << 22) +#define OMAP_ULPI_START (1 << 31)
/* - * Wait for the ULPI Access to complete + * Wait for having ulpi in done state */ static int ulpi_wait(struct ulpi_viewport *ulpi_vp, u32 mask) { int timeout = CONFIG_USB_ULPI_TIMEOUT;
while (--timeout) { - if ((readl(ulpi_vp->viewport_addr) & mask)) + if (!(readl(ulpi_vp->viewport_addr) & mask)) return 0;
udelay(1); @@ -43,40 +44,15 @@ static int ulpi_wait(struct ulpi_viewport *ulpi_vp, u32 mask) }
/* - * Wake the ULPI PHY up for communication - * - * returns 0 on success. - */ -static int ulpi_wakeup(struct ulpi_viewport *ulpi_vp) -{ - int err; - - if (readl(ulpi_vp->viewport_addr) & OMAP_ULPI_ACCESS) - return 0; /* already awake */ - - writel(OMAP_ULPI_ACCESS, ulpi_vp->viewport_addr); - - err = ulpi_wait(ulpi_vp, OMAP_ULPI_ACCESS); - if (err) - debug("ULPI wakeup timed out\n"); - - return err; -} - -/* * Issue a ULPI read/write request */ static int ulpi_request(struct ulpi_viewport *ulpi_vp, u32 value) { int err;
- err = ulpi_wakeup(ulpi_vp); - if (err) - return err; - writel(value, ulpi_vp->viewport_addr);
- err = ulpi_wait(ulpi_vp, OMAP_ULPI_ACCESS); + err = ulpi_wait(ulpi_vp, OMAP_ULPI_START); if (err) debug("ULPI request timed out\n");
@@ -85,7 +61,7 @@ static int ulpi_request(struct ulpi_viewport *ulpi_vp, u32 value)
int ulpi_write(struct ulpi_viewport *ulpi_vp, u8 *reg, u32 value) { - u32 val = ((ulpi_vp->port_num & 0xf) << 24) | + u32 val = OMAP_ULPI_START | (((ulpi_vp->port_num + 1) & 0xf) << 24) | OMAP_ULPI_WR_OPSEL | ((u32)reg << 16) | (value & 0xff);
return ulpi_request(ulpi_vp, val); @@ -94,8 +70,8 @@ int ulpi_write(struct ulpi_viewport *ulpi_vp, u8 *reg, u32 value) u32 ulpi_read(struct ulpi_viewport *ulpi_vp, u8 *reg) { int err; - u32 val = ((ulpi_vp->port_num & 0xf) << 24) | - OMAP_ULPI_WR_OPSEL | ((u32)reg << 16); + u32 val = OMAP_ULPI_START | (((ulpi_vp->port_num + 1) & 0xf) << 24) | + OMAP_ULPI_RD_OPSEL | ((u32)reg << 16);
err = ulpi_request(ulpi_vp, val); if (err)
Hi Michael,
On 10/06/13 12:55, Michael Trimarchi wrote:
Hi
On Mon, Jun 10, 2013 at 11:54:31AM +0300, Lubomir Popov wrote:
Hi Michael,
On 10/06/13 00:37, Michael Trimarchi wrote:
Hi
On 06/08/2013 10:43 PM, Lubomir Popov wrote:
Hi Tom, Michael,
Hello,
The following changes since commit 3da0e5750b24a9491058df6126c7be577a276c09:
arm: factorize relocate_code routine (2013-05-30 20:24:38 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-ti.git master
for you to fetch changes up to 80dd596d1b442ff53dbeb33eccdb8efd2283be79:
[snip]
Michael Trimarchi (1): usb: omap: ulpi: fix ulpi transceiver access
[snip]
drivers/usb/ulpi/omap-ulpi-viewport.c | 40 +-
[snip]
I just made a clean clone of u-boot-ti/master, manually applied the changes to the ehci files, added my board files and made a build. Everything seems to work fine, but I see an error message regarding ULPI reset that was not present before, and obviously it is due to Michael's changes:
SOM5_EVB # usb start (Re)start USB... USB0: ULPI: ulpi_reset: failed writing reset bit
Let me understand. The patch is wrong because you have a problem now. The old code was not sending any write command so any ulpi_reset and the test condition was wrong.
Right.
USB EHCI 1.00 scanning bus 0 for devices... 6 USB Device(s) found scanning usb for storage devices... 3 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found SOM5_EVB # usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Mass Storage (480 Mb/s, 200mA) | FSC MEMORYBIRD USB2 C157040817120315AA | +-3 Hub (480 Mb/s, 2mA) | | | +-4 Mass Storage (480 Mb/s, 96mA) | | Generic Ultra Fast Media Reader 000000264001 | | | +-5 Mass Storage (480 Mb/s, 100mA) | USB Flash Drive 531C43B21928F11F | +-6 Vendor specific (480 Mb/s, 500mA)
SOM5_EVB #
Otherwise everything is OK, the device on the ULPI port is working (it is #2 above). It is now late and I shall investigate in detail tomorrow, this is just an early warning ;)
Can you test the attach patch? Yes I know it is not inline but I will send inline tomorrow and I have done changing the old one. I was thinking port number was starting from 1 but I have done a quick check on soft_reset of omap and it is starting from 0
Just tested on a OMAP5430 custom board. Everything is OK, PHY soft reset passes. My ULPI PHY is on port 0, and with the previous version the insreg05 bit 31 remained stuck at 1, producing this error. Now when we write 1 to the port field instead of 0, everything is fine. So
Tested-by: Lubomir Popov lpopov@mm-sol.com
While testing, I however encountered another issue (not related to this patch, take it easy ;-) ): one particular USB flash stick, connected to the ULPI port, does systematically (100%) not get detected upon the first 'usb start' command after power-on; subsequent usb start/reset commands detect it alright. I have experimented a bit with some delays (assuming that it is some sort of timing problem), but without success. Other sticks are OK. Removing the call to omap_ehci_soft_phy_reset() (which calls ulpi_reset() and the viewport stuff) does not change anything.
I'm currently at work, where I have other obligations and cannot spend much time for U-Boot. Therefore, if somebody could share any experience on this subject, please let me know.
One thing that perhaps I should clarify: my ULPI PHY is the TI part TUSB1210; on the other hand, TI themselves recommend PHYs by SMSC, at least for the OMAP4. This was not the case for OMAP5, but who knows...
Thanks, Lubo
Michael
Best regards, Lubo
This patch fix the omap access to the transceiver configuration registers using the ulpi bus. As reported by the documentation the bit31 is used only to check if the transaction is done or still running and the reading and writing operation have different offset and have different values. What we need to do at the end of a transaction is leave the bus in done state. Anyway an error using the ulpi omap register is not recoverable so any error give out the usage of this interface.
Signed-off-by: Michael Trimarchi michael@amarulasolutions.com
- changes for V4
we use the omap access function.
- port_num start from 0 so we need to take in account when
- Fix the read function
- changes for V3 Fix patch subject
- changes for V2 Fix commit message
drivers/usb/ulpi/omap-ulpi-viewport.c | 42 +++++++-------------------------- 1 file changed, 9 insertions(+), 33 deletions(-)
diff --git a/drivers/usb/ulpi/omap-ulpi-viewport.c b/drivers/usb/ulpi/omap-ulpi-viewport.c index 3c1ea1a..4db7fa4 100644 --- a/drivers/usb/ulpi/omap-ulpi-viewport.c +++ b/drivers/usb/ulpi/omap-ulpi-viewport.c @@ -22,18 +22,19 @@ #include <asm/io.h> #include <usb/ulpi.h>
-#define OMAP_ULPI_WR_OPSEL (3 << 21) -#define OMAP_ULPI_ACCESS (1 << 31) +#define OMAP_ULPI_WR_OPSEL (2 << 22) +#define OMAP_ULPI_RD_OPSEL (3 << 22) +#define OMAP_ULPI_START (1 << 31)
/*
- Wait for the ULPI Access to complete
*/
- Wait for having ulpi in done state
static int ulpi_wait(struct ulpi_viewport *ulpi_vp, u32 mask) { int timeout = CONFIG_USB_ULPI_TIMEOUT;
while (--timeout) {
if ((readl(ulpi_vp->viewport_addr) & mask))
if (!(readl(ulpi_vp->viewport_addr) & mask)) return 0;udelay(1);
@@ -43,40 +44,15 @@ static int ulpi_wait(struct ulpi_viewport *ulpi_vp, u32 mask) }
/*
- Wake the ULPI PHY up for communication
- returns 0 on success.
- */
-static int ulpi_wakeup(struct ulpi_viewport *ulpi_vp) -{
- int err;
- if (readl(ulpi_vp->viewport_addr) & OMAP_ULPI_ACCESS)
return 0; /* already awake */- writel(OMAP_ULPI_ACCESS, ulpi_vp->viewport_addr);
- err = ulpi_wait(ulpi_vp, OMAP_ULPI_ACCESS);
- if (err)
debug("ULPI wakeup timed out\n");- return err;
-}
-/*
- Issue a ULPI read/write request
*/ static int ulpi_request(struct ulpi_viewport *ulpi_vp, u32 value) { int err;
err = ulpi_wakeup(ulpi_vp);
if (err)
return err;writel(value, ulpi_vp->viewport_addr);
err = ulpi_wait(ulpi_vp, OMAP_ULPI_ACCESS);
- err = ulpi_wait(ulpi_vp, OMAP_ULPI_START); if (err) debug("ULPI request timed out\n");
@@ -85,7 +61,7 @@ static int ulpi_request(struct ulpi_viewport *ulpi_vp, u32 value)
int ulpi_write(struct ulpi_viewport *ulpi_vp, u8 *reg, u32 value) {
- u32 val = ((ulpi_vp->port_num & 0xf) << 24) |
u32 val = OMAP_ULPI_START | (((ulpi_vp->port_num + 1) & 0xf) << 24) | OMAP_ULPI_WR_OPSEL | ((u32)reg << 16) | (value & 0xff);
return ulpi_request(ulpi_vp, val);
@@ -94,8 +70,8 @@ int ulpi_write(struct ulpi_viewport *ulpi_vp, u8 *reg, u32 value) u32 ulpi_read(struct ulpi_viewport *ulpi_vp, u8 *reg) { int err;
- u32 val = ((ulpi_vp->port_num & 0xf) << 24) |
OMAP_ULPI_WR_OPSEL | ((u32)reg << 16);
- u32 val = OMAP_ULPI_START | (((ulpi_vp->port_num + 1) & 0xf) << 24) |
OMAP_ULPI_RD_OPSEL | ((u32)reg << 16);
This fix (OMAP_ULPI_START | ...) to ulpi_read() is correct. It does not however solve my issue :( . As I noted, with or without calling the soft reset, behavior with this particular USB stick is the same.
err = ulpi_request(ulpi_vp, val); if (err)
BR, Lubo
Hi Michael,
On Mon, 10 Jun 2013 11:55:31 +0200, Michael Trimarchi michael@amarulasolutions.com wrote:
This patch fix the omap access to the transceiver
Please do not post new patches inside an existing thread, especially a pull request thread.
Amicalement,
On Mon, Jun 10, 2013 at 11:55:31AM +0200, Michael Trimarchi wrote:
Hi
On Mon, Jun 10, 2013 at 11:54:31AM +0300, Lubomir Popov wrote:
Hi Michael,
On 10/06/13 00:37, Michael Trimarchi wrote:
Hi
On 06/08/2013 10:43 PM, Lubomir Popov wrote:
Hi Tom, Michael,
Hello,
The following changes since commit 3da0e5750b24a9491058df6126c7be577a276c09:
arm: factorize relocate_code routine (2013-05-30 20:24:38 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-ti.git master
for you to fetch changes up to 80dd596d1b442ff53dbeb33eccdb8efd2283be79:
[snip]
Michael Trimarchi (1): usb: omap: ulpi: fix ulpi transceiver access
[snip]
drivers/usb/ulpi/omap-ulpi-viewport.c | 40 +-
[snip]
I just made a clean clone of u-boot-ti/master, manually applied the changes to the ehci files, added my board files and made a build. Everything seems to work fine, but I see an error message regarding ULPI reset that was not present before, and obviously it is due to Michael's changes:
SOM5_EVB # usb start (Re)start USB... USB0: ULPI: ulpi_reset: failed writing reset bit
Let me understand. The patch is wrong because you have a problem now. The old code was not sending any write command so any ulpi_reset and the test condition was wrong.
Right.
USB EHCI 1.00 scanning bus 0 for devices... 6 USB Device(s) found scanning usb for storage devices... 3 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found SOM5_EVB # usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Mass Storage (480 Mb/s, 200mA) | FSC MEMORYBIRD USB2 C157040817120315AA | +-3 Hub (480 Mb/s, 2mA) | | | +-4 Mass Storage (480 Mb/s, 96mA) | | Generic Ultra Fast Media Reader 000000264001 | | | +-5 Mass Storage (480 Mb/s, 100mA) | USB Flash Drive 531C43B21928F11F | +-6 Vendor specific (480 Mb/s, 500mA)
SOM5_EVB #
Otherwise everything is OK, the device on the ULPI port is working (it is #2 above). It is now late and I shall investigate in detail tomorrow, this is just an early warning ;)
Can you test the attach patch? Yes I know it is not inline but I will send inline tomorrow and I have done changing the old one. I was thinking port number was starting from 1 but I have done a quick check on soft_reset of omap and it is starting from 0
Just tested on a OMAP5430 custom board. Everything is OK, PHY soft reset passes. My ULPI PHY is on port 0, and with the previous version the insreg05 bit 31 remained stuck at 1, producing this error. Now when we write 1 to the port field instead of 0, everything is fine. So
Tested-by: Lubomir Popov lpopov@mm-sol.com
While testing, I however encountered another issue (not related to this patch, take it easy ;-) ): one particular USB flash stick, connected to the ULPI port, does systematically (100%) not get detected upon the first 'usb start' command after power-on; subsequent usb start/reset commands detect it alright. I have experimented a bit with some delays (assuming that it is some sort of timing problem), but without success. Other sticks are OK. Removing the call to omap_ehci_soft_phy_reset() (which calls ulpi_reset() and the viewport stuff) does not change anything.
I'm currently at work, where I have other obligations and cannot spend much time for U-Boot. Therefore, if somebody could share any experience on this subject, please let me know.
One thing that perhaps I should clarify: my ULPI PHY is the TI part TUSB1210; on the other hand, TI themselves recommend PHYs by SMSC, at least for the OMAP4. This was not the case for OMAP5, but who knows...
Thanks, Lubo
Michael
Best regards, Lubo
This patch fix the omap access to the transceiver configuration registers using the ulpi bus. As reported by the documentation the bit31 is used only to check if the transaction is done or still running and the reading and writing operation have different offset and have different values. What we need to do at the end of a transaction is leave the bus in done state. Anyway an error using the ulpi omap register is not recoverable so any error give out the usage of this interface.
Signed-off-by: Michael Trimarchi michael@amarulasolutions.com
Thanks for sorting this all out. Please post as a separate thread the new patch, and I'm going to drop the ULPI patch from my pull request for now (we'll pick it up before release). Thanks!
Hi Tom,
On Fri, 7 Jun 2013 15:19:21 -0400, Tom Rini trini@ti.com wrote:
Tom Rini (4):
arm: Remove OMAP2420H4 and all omap24xx support
This one removes not only 2420h4 but also tnetv107x_evm. Is that normal?
Amicalement,
On Sat, Jun 08, 2013 at 11:57:05PM +0200, Albert ARIBAUD wrote:
Hi Tom,
On Fri, 7 Jun 2013 15:19:21 -0400, Tom Rini trini@ti.com wrote:
Tom Rini (4):
arm: Remove OMAP2420H4 and all omap24xx supportThis one removes not only 2420h4 but also tnetv107x_evm. Is that normal?
That wasn't intentional, merge problem and/or fat-fingers. Re-did that commit and rebased onto current u-boot-arm, will re-do a pull request once MAKEALL -a arm finishes.
participants (5)
-
Albert ARIBAUD -
Igor Grinberg -
Lubomir Popov -
Michael Trimarchi -
Tom Rini