Hi Heiko,
Hello Simon, Lubomir,
Am 03.02.2015 01:59, schrieb Simon Glass:
Hi,
On 30 January 2015 at 10:56, Lubomir Popov lpo...@mm-sol.com wrote:
I2C chips do exist that require a write of some multi-byte data to occur in
a single bus transaction (aka atomic transfer), otherwise either
Hi Simon,
Hi,
On 30 January 2015 at 10:56, Lubomir Popov lpo...@mm-sol.com wrote:
I2C chips do exist that require a write of some multi-byte data to occur in
a single bus transaction (aka atomic transfer), otherwise either the write
does not come into effect at all, or normal operation
in a single bus transaction if
the '-s' option is specified as a final command argument. Else the current
re-addressing method is used.
Signed-off-by: Lubomir Popov l-po...@ti.com
---
Changes in V3:
Rebased on current master.
Changes in V2:
The option to use bulk transfer vs re-addressing
Hi Heiko,
Hello Lubomir,
Am 24.11.2014 17:00, schrieb Lubomir Popov:
I2C chips do exist that require a write of some multi-byte data to occur in
a single bus transaction (aka atomic transfer), otherwise either the write
does not come into effect at all, or normal operation of internal
Hi Heiko,
Hello Lubomir,
Am 28.01.2015 09:32, schrieb Lubomir Popov:
Hi Heiko,
Hello Lubomir,
Am 24.11.2014 17:00, schrieb Lubomir Popov:
I2C chips do exist that require a write of some multi-byte data to occur in
a single bus transaction (aka atomic transfer), otherwise either
-by: Lubomir Popov l-po...@ti.com
---
Tested on the Vayu and J6Eco EVMs.
arch/arm/cpu/armv7/omap-common/clocks-common.c | 83 ++--
arch/arm/cpu/armv7/omap5/hw_data.c | 43 ++--
arch/arm/include/asm/arch-omap5/clock.h| 20 +-
3 files changed, 118
Tom,
Even if this patch is not applied if considered useless, the one fixing
the clocks (http://patchwork.ozlabs.org/patch/410834/) should be, in my
opinion, as it is essentially a bug fix. Now, for the DRA7xx SoCs,
1) a write to a undefined (or zero) register address is occurring since
struct
Hi Simon,
Hi,
On 24 November 2014 at 09:00, Lubomir Popov lpo...@mm-sol.com wrote:
I2C chips do exist that require a write of some multi-byte data to occur in
a single bus transaction (aka atomic transfer), otherwise either the write
does not come into effect at all, or normal operation
in a single bus transaction if
the '-s' option is specified as a final command argument. Else the current
re-addressing method is used.
Signed-off-by: Lubomir Popov l-po...@ti.com
---
Changes in V2:
The option to use bulk transfer vs re-addressing is implemented as a run-time
command argument
Hi Simon,
[snip]
+ while (length-- 0) {
+ if (i2c_write(chip, devaddr++, alen, memaddr++, 1)
!= 0)
+ return i2c_report_err(-1, I2C_ERR_WRITE);
/*
* No write delay with FRAM devices.
*/
Should this be indented?
in a single bus transaction if
CONFIG_SYS_I2C_BULK_WRITE is defined in the board header (otherwise the old
method shall compile).
Signed-off-by: Lubomir Popov l-po...@ti.com
---
common/cmd_i2c.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/common/cmd_i2c.c b
Hi Tom,
On Fri, Nov 14, 2014 at 03:20:44PM +0200, Lubomir Popov wrote:
On the J6Eco EVM we have two on-board devices on the I2C5 bus; this
bus is also routed to the camera and expansion connectors. I2C4 is
routed to one of the expansion connectors. This patch enables usage
of these two
Unlike regular OMAP5, on the DRA7xx SoCs the I2C5 module belongs to
the IPU clock domain. This patch takes care of the appropriate clock
preparation and makes I2C5 operational - it fixes the 'data abort'
exception that otherwise happened upon accessing the I2C5 controller.
Signed-off-by: Lubomir
is required as a prerequisite.
Tested on a J6 ECO EVM rev.B with a DRA726 ES1.0.
Signed-off-by: Lubomir Popov l-po...@ti.com
---
board/ti/dra7xx/evm.c |7 +++
board/ti/dra7xx/mux_data.h |8
2 files changed, 15 insertions(+)
diff --git a/board/ti/dra7xx/evm.c b/board/ti
If print_mmc_devices() was called with a '\n' separator (as done
for example by the mmc list command), it offset the 2-nd and
all subsequent lines by one space. Fixing this.
Signed-off-by: Lubomir Popov l-po...@ti.com
---
drivers/mmc/mmc.c |7 +--
1 file changed, 5 insertions(+), 2
Tested on a Vayu EVM Rev.E2 with DRA752 ES1.1
Signed-off-by: Lubomir Popov l-po...@ti.com
---
include/configs/dra7xx_evm.h |1 +
1 file changed, 1 insertion(+)
diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index 2eaabde..174a711 100644
--- a/include/configs
The comments on the QSPI pad assignments erronously swapped
the qspi1_d0 and qspi1_d1 functionality and could cause
confusion. QSPI1_D[0] is in fact muxed on pad U1 (gpmc_a16),
and QSPI1_D[1] - on pad P3 (gpmc_a17). Fixing comments.
Signed-off-by: Lubomir Popov l-po...@ti.com
---
board/ti/dra7xx
OMAP4
board (with one USB4640 HSIC hub; tested with OMAP4460 and 4470).
Lubomir Popov (2):
ARM: OMAP4/5: Add alternative method for HSIC USB devices reset
ARM: omap5_uevm: Example usage of alternative HSIC USB device reset
board/ti/omap5_uevm/evm.c|2 +
drivers/usb/host/ehci-hcd.c | 15
on all OMAP543x-ES1.0 ports.
Signed-off-by: Lubomir Popov l-po...@ti.com
---
drivers/usb/host/ehci-hcd.c | 15
drivers/usb/host/ehci-omap.c | 174 +-
2 files changed, 170 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers
of the second call to omap_ehci_hcd_init() after reset
which is not needed anymore.
On some other OMAP4/5 boards however this is the only method that
works.
Signed-off-by: Lubomir Popov l-po...@ti.com
---
board/ti/omap5_uevm/evm.c|2 ++
include/configs/omap5_uevm.h | 13 ++---
2 files
All prerequisites are already available, so why not enable 8-bit
access - it is a matter of a define in the board file only.
Signed-off-by: Lubomir Popov l-po...@ti.com
---
include/configs/omap5_uevm.h |1 +
1 file changed, 1 insertion(+)
diff --git a/include/configs/omap5_uevm.h b/include
on all OMAP543x-ES1.0 ports.
Signed-off-by: Lubomir Popov l-po...@ti.com
---
V1 got garbled during transmission, don't know why. V2 is just a resend.
drivers/usb/host/ehci-hcd.c | 15
drivers/usb/host/ehci-omap.c | 174 +-
2 files changed, 170
on all OMAP543x-ES1.0 ports.
Signed-off-by: Lubomir Popov l-po...@ti.com
---
V1 and V2 got garbled during transmission. V3 is just a resend (again).
drivers/usb/host/ehci-hcd.c | 15
drivers/usb/host/ehci-omap.c | 174 +-
2 files changed, 170
on all OMAP543x-ES1.0 ports.
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
---
V4 is just a resend from another machine. V1/2/3 were corrupted during
transmission.
drivers/usb/host/ehci-hcd.c | 15
drivers/usb/host/ehci-omap.c | 174 ++-
2 files changed
Hi Tom,
On 05-Dec-13 0:04, Tom Rini wrote:
On Wed, Nov 20, 2013 at 03:32:17PM +0200, Lubomir Popov wrote:
The struct incorrectly referenced SMPS1 for all three power
domains. Fixed this by using SMPS2 and SMPS5 as appropriate.
Add some comments and choose voltage values that correspond
Hi Lokesh,
On 03/12/13 06:02, Lokesh Vutla wrote:
Hi Lubomir,
On Monday 02 December 2013 09:17 PM, Lubomir Popov wrote:
Hi Nikita,
On 28/11/13 18:04, Nikita Kiryanov wrote:
Writing zero into I2Ci.I2C_CNT register causes random I2C failures in OMAP3
based devices. This seems to be related
register.
Cc: Heiko Schocher h...@denx.de
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Tom Rini tr...@ti.com
Cc: Lubomir Popov lpo...@mm-sol.com
Cc: Enric Balletbo Serra eballe...@gmail.com
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
---
Changes in V2:
Removed all
register.
Cc: Heiko Schocher h...@denx.de
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Tom Rini tr...@ti.com
Cc: Lubomir Popov lpo...@mm-sol.com
Cc: Enric Balletbo Serra eballe...@gmail.com
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
---
Changes in V2:
Removed all
Hi Nikita,all,
On 27-Nov-13 17:52, Nikita Kiryanov wrote:
On 11/27/2013 05:28 PM, Thomas Petazzoni wrote:
Dear Nikita Kiryanov,
On Wed, 27 Nov 2013 16:52:56 +0200, Nikita Kiryanov wrote:
Not sure to understand your question: my paragraph above mentions the
IGEP board as being the platform
Hi Tom,
On Wed, Nov 27, 2013 at 06:01:18PM +0200, Lubomir Popov wrote:
Hi Nikita,all,
On 27-Nov-13 17:52, Nikita Kiryanov wrote:
On 11/27/2013 05:28 PM, Thomas Petazzoni wrote:
Dear Nikita Kiryanov,
On Wed, 27 Nov 2013 16:52:56 +0200, Nikita Kiryanov wrote:
Not sure to understand your
The struct incorrectly referenced SMPS1 for all three power
domains. Fixed this by using SMPS2 and SMPS5 as appropriate.
Add some comments and choose voltage values that correspond
to voltage selection codes.
Signed-off-by: Lubomir Popov l-po...@ti.com
---
arch/arm/cpu/armv7/omap4/hw_data.c
Hi Nikita,
On 11-Nov-13 13:15, Nikita Kiryanov wrote:
On 11/08/2013 11:26 PM, Lubomir Popov wrote:
Hi Nikita,
On 11/06/2013 03:19 PM, Lubomir Popov wrote:
On 06-Nov-13 14:12, Nikita Kiryanov wrote:
In drivers/i2c/omap24xx_i2c.c there are a few checks that attempt to
detect unconfigured
Hi Nikita,
On 11/06/2013 03:19 PM, Lubomir Popov wrote:
On 06-Nov-13 14:12, Nikita Kiryanov wrote:
In drivers/i2c/omap24xx_i2c.c there are a few checks that attempt to
detect unconfigured pads for the i2c bus in use. These checks are
all in the form of
if (status == I2C_STAT_XRDY
Heiko,
On 07-Nov-13 10:04, Heiko Schocher wrote:
Hello Lubomir,
Am 07.11.2013 08:57, schrieb Lubomir Popov:
Hi Heiko,
On 07-Nov-13 7:14, Heiko Schocher wrote:
Hello Lubomir,
Am 06.11.2013 14:19, schrieb Lubomir Popov:
On 06-Nov-13 14:12, Nikita Kiryanov wrote:
In drivers/i2c
On 06-Nov-13 14:12, Nikita Kiryanov wrote:
In drivers/i2c/omap24xx_i2c.c there are a few checks that attempt to
detect unconfigured pads for the i2c bus in use. These checks are
all in the form of
if (status == I2C_STAT_XRDY) {
printf(unconfigured pads\n);
return -1;
}
This check seems
Hi Heiko,
On 07-Nov-13 7:14, Heiko Schocher wrote:
Hello Lubomir,
Am 06.11.2013 14:19, schrieb Lubomir Popov:
On 06-Nov-13 14:12, Nikita Kiryanov wrote:
In drivers/i2c/omap24xx_i2c.c there are a few checks that attempt to
detect unconfigured pads for the i2c bus in use. These checks are
all
Hi Robert,
On 20/08/13 23:46, Robert P. J. Day wrote:
playing on my beaglebone black and:
U-Boot# mmc list
OMAP SD/MMC: 0
OMAP SD/MMC: 1 -- ???
U-Boot#
puzzled as to why the second line is indented, and discovered, first
from cmd_mmc.c:
print_mmc_devices('\n');
devices by
inserting a 20 us delay between writing arguments and command. This
solution has been proposed by Michael Cashwell mboa...@prograde.net.
A minor cosmetic fix in a comment as well.
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
---
Tested on a custom OMAP5430 board with a SanDisk 8 GB eMMC
devices by
inserting a 20 us delay between writing arguments and command. This
solution has been proposed by Michael Cashwell mboa...@prograde.net.
A minor cosmetic fix in a comment as well.
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
---
V2 fixes the actual write to mmc-host_caps (missed in V1
Hi Dan,
On 26/07/13 03:30, Dan Murphy wrote:
Lubo
Thanks for the reply
On 07/25/2013 03:38 PM, Lubomir Popov wrote:
Hi Dan, guys,
Just would like to give my 5 cents: my humble experience with
OMAP4 and OMAP5 tells me that this (that is, the need to reset
devices after applying port
Hi Dan, guys,
Just would like to give my 5 cents: my humble experience with
OMAP4 and OMAP5 tells me that this (that is, the need to reset
devices after applying port power) seems to be a OMAP5 HSIC IP
issue, and not a device problem. We at MMS have two custom
designs, one with OMAP5430 and one
Hi Tom, Marek,
On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini tr...@ti.com wrote:
Hey all,
I've tagged and pushed v2013.07-rc2. A bit more over the place than I
should have gone, but picked up a lot of things that have been
outstanding for a while. The big thing is a refactor of the boot loop.
---
Entire series
Tested-by: Lubomir Popov lpo...@mm-sol.com
on MacOS X 10.8.3 with the following tools used for building U-Boot
for one ARM (OMAP) board:
arm-none-eabi-gcc (GCC) 4.7.2
GNU ld (GNU Binutils) 2.23.1
Best regards,
Lubo
___
U-Boot mailing list
BSD (like OS X) variants of regex.h do not declare REG_NOERROR, add a simple
define for them.
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
---
Tested-by: Lubomir Popov lpo...@mm-sol.com
___
U-Boot mailing list
U-Boot@lists.denx.de
Some OS (like OS X) do not provide a generic readelf. We should enforce to use
the toochain provided readelf instead, to do so use $(CROSS_COMPILE)readelf.
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
---
Tested-by: Lubomir Popov lpo...@mm-sol.com
Hi Simon,
On 28/06/13 10:02, Andreas Bießmann wrote:
Hi Simon,
On 28.06.13 08:52, Simon Glass wrote:
Hi Andreas,
On Thu, Jun 27, 2013 at 11:48 PM, Andreas Bießmann
andreas.de...@googlemail.com mailto:andreas.de...@googlemail.com wrote:
snip
+# TODO(s...@chromium.org
Hi Axel,
On 21/06/13 06:07, Axel Lin wrote:
AM33XX has 4 gpio banks, thus the valid gpio range should be 0 ... 127.
Signed-off-by: Axel Lin axel@ingics.com
---
v2: define OMAP_MAX_GPIO and use it.
This change is mainly based on Stefan's comment, however I use
OMAP_MAX_GPIO instead of
Hi Axel,
On 21/06/13 10:13, Axel Lin wrote:
2013/6/21 Lubomir Popov lpo...@mm-sol.com:
Hi Axel,
On 21/06/13 06:07, Axel Lin wrote:
AM33XX has 4 gpio banks, thus the valid gpio range should be 0 ... 127.
Signed-off-by: Axel Lin axel@ingics.com
---
v2: define OMAP_MAX_GPIO and use
do you think?
Thanks,
Lubo
On 21/06/13 10:29, Lubomir Popov wrote:
Hi Axel,
On 21/06/13 10:13, Axel Lin wrote:
2013/6/21 Lubomir Popov lpo...@mm-sol.com:
Hi Axel,
On 21/06/13 06:07, Axel Lin wrote:
AM33XX has 4 gpio banks, thus the valid gpio range should be 0 ... 127.
Signed-off
Hi Heiko, Axel,
On 21/06/13 11:44, Heiko Schocher wrote:
Hello Lubomir,
Am 21.06.2013 09:44, schrieb Lubomir Popov:
One more thing that perhaps seems more reasonable in general:
These OMAP_MAX_GPIO defines could go into the corresponding .../arch-omap*.h
files, where the base addresses
Axel,
Why do you introduce a function when this stuff is constant and known
to the compiler? Just put a #define in every header. You are now
uselessly inflating code...
Regards,
Lubo
On 21/06/13 11:50, Axel Lin wrote:
Now the omap_gpio driver is used by AM33XX, OMAP3/4, OMAP54XX and DRA7XX
to all arch/arm/include/asm/arch-omap*/gpio.h.
2. Update gpio bank settings and enable GPIO modules 7 8 clocks for OMAP5.
Thanks for Lubomir Popov to provide valuable comments to fix this issue.
Signed-off-by: Axel Lin axel@ingics.com
---
This patch supersedes below patches:
[PATCH v3
On 16.06.2013 17:46, Simon Glass wrote:
This error may not be defined on some platforms such as MacOS so host
compilation will fail. Use one of the more common errors instead.
Signed-off-by: Simon Glass s...@chromium.org
Tested-by: Lubomir Popov lpo...@mm-sol.com
on MacOS X 10.8.3
Hi Tom,
Hey all,
I've tagged and pushed v2013.07-rc1. Lots of things all over the place.
If you've got changes outstanding still, please start gently poking
custodians with patchwork links. I've got a good bit of stuff I need to
deal with myself still, but please prod me all the same.
Hi Simon,
Hi Lubo,
On Sun, Jun 16, 2013 at 4:49 AM, Lubomir Popov lpo...@mm-sol.com wrote:
Hi Tom,
Hey all,
I've tagged and pushed v2013.07-rc1. Lots of things all over the place.
If you've got changes outstanding still, please start gently poking
custodians with patchwork links
Hi Simon,
Hi Lubo,
On Sun, Jun 16, 2013 at 9:35 AM, Lubomir Popov lpo...@mm-sol.com wrote:
Hi Simon,
Hi Lubo,
On Sun, Jun 16, 2013 at 4:49 AM, Lubomir Popov lpo...@mm-sol.com
wrote:
Hi Tom,
Hey all,
I've tagged and pushed v2013.07-rc1. Lots of things all over
completion still works, etc.
Applied the series to a relatively fresh (yesterday's) u-boot-ti/master
and tested on a custom OMAP5430 board. Boots normally. USB storage and
Ethernet (dhcp ping), SD/MMC, I2C are all working.
Tested-by: Lubomir Popov lpo...@mm-sol.com
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
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
with a TUSB1210
ULPI PHY on USBB1:
Tested-by: Lubomir Popov lpo...@mm-sol.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hi Michael,
On 10/06/13 17:23, Michael Trimarchi wrote:
Fix ulpi reading and writing function.
* Both functions need to have the bit31 setted.
* Right now uboot use 0 to enumerate port 1 and 1 to
enumerate port 2 and so on. Omap code use 1 for port 1 and 2 for port 2.
Add a +1 fix
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
Hi Tom,
On 05/06/13 16:45, Tom Rini wrote:
On Wed, Jun 05, 2013 at 11:03:26AM +0300, Lubomir Popov wrote:
Hi Tom,
On 05/06/13 00:06, Tom Rini wrote:
On Mon, Jun 03, 2013 at 10:58:27PM +0300, Lubomir Popov wrote:
Hi Lokesh,
Hi Lubomir,
On Thursday 30 May 2013 07:56 PM, Lubomir Popov
Hi Tom,
On 26/05/13 23:03, Lubomir Popov wrote:
The newly introduced function setup_warmreset_time(), called
from within prcm_init(), tries to write to the prm_rsttime
OMAP5 register. The struct member holding this register's
address is however initialized for OMAP5 ES2.0 only. On ES1.0
Hi Lokesh,
On 06/06/13 14:26, Lokesh Vutla wrote:
Hi Lubomir,
On Thursday 06 June 2013 12:55 PM, Lubomir Popov wrote:
Hi Tom,
On 05/06/13 16:45, Tom Rini wrote:
On Wed, Jun 05, 2013 at 11:03:26AM +0300, Lubomir Popov wrote:
[snip]
OK, lets see. That so lets keep your patch as-is, since
Add some useful functions, and the corresponding definitions.
Add support for powering on the dra7xx_evm SD/MMC LDO
(courtesy Lokesh Vutla lokeshvu...@ti.com).
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
---
V3 does some cleanup and adds support for the dra7xx_evm
board (power on LDO1 used
Hi Tom,
On 06/06/13 16:26, Tom Rini wrote:
On Thu, Jun 06, 2013 at 04:58:44PM +0530, Lokesh Vutla wrote:
Hi Tom,
On Thursday 30 May 2013 06:49 PM, Lokesh Vutla wrote:
This series update support for DRA7xx family Socs and the data for
DRA752 ES1.0 soc.
This is on top of my recent Misc
Add some useful functions, and the corresponding definitions.
Add support for powering on the dra7xx_evm SD/MMC LDO
(courtesy Lokesh Vutla lokeshvu...@ti.com).
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
---
V4 checkpatch-clean (except for one long printf string).
V3 does some cleanup
Hi Dan,
Update the EXTRA_ENV_SETTING for the dra7xx.
The console needs to be set to ttyO0 and the
findfdt needs to be updated to load the
dra7xx-evm.dtb file.
Signed-off-by: Dan Murphy dmur...@ti.com
---
v4 - Remove check for undefined fdtfile and save for another patch -
Hi Tom,
On 05/06/13 00:06, Tom Rini wrote:
On Mon, Jun 03, 2013 at 10:58:27PM +0300, Lubomir Popov wrote:
Hi Lokesh,
Hi Lubomir,
On Thursday 30 May 2013 07:56 PM, Lubomir Popov wrote:
Hi Lokesh,
On 30/05/13 16:19, Lokesh Vutla wrote:
From: Balaji T K balaj...@ti.com
add dra mmc pbias
Hi Nishanth,
On 05/06/13 17:01, Nishanth Menon wrote:
On Wed, Jun 5, 2013 at 3:03 AM, Lubomir Popov lpo...@mm-sol.com wrote:
Hi Tom,
On 05/06/13 00:06, Tom Rini wrote:
On Mon, Jun 03, 2013 at 10:58:27PM +0300, Lubomir Popov wrote:
Hi Lokesh,
Hi Lubomir,
On Thursday 30 May 2013 07:56 PM
Hi Nishanth,
On Wed, Jun 5, 2013 at 11:35 AM, Lubomir Popov lpo...@mm-sol.com wrote:
Hi Nishanth,
On 05/06/13 17:01, Nishanth Menon wrote:
On Wed, Jun 5, 2013 at 3:03 AM, Lubomir Popov lpo...@mm-sol.com wrote:
Hi Tom,
On 05/06/13 00:06, Tom Rini wrote:
On Mon, Jun 03, 2013 at 10:58:27PM
Hi Heiko,
On 04/06/13 07:26, Heiko Schocher wrote:
Hello Lubomir,
Am 03.06.2013 07:13, schrieb Heiko Schocher:
Hello Lubomir,
Am 02.06.2013 13:42, schrieb Lubomir Popov:
Hello Lubomir,
Am 01.06.2013 18:44, schrieb Lubomir Popov:
New i2c_read, i2c_write and i2c_probe functions, tested
Hi Lokesh,
Hi Lubomir,
On Thursday 30 May 2013 07:56 PM, Lubomir Popov wrote:
Hi Lokesh,
On 30/05/13 16:19, Lokesh Vutla wrote:
From: Balaji T K balaj...@ti.com
add dra mmc pbias support and ldo1 power on
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu
Hello Lubomir,
Am 01.06.2013 18:44, schrieb Lubomir Popov:
New i2c_read, i2c_write and i2c_probe functions, tested on OMAP4
(4430/60/70), OMAP5 (5430) and AM335X (3359); should work on older
OMAPs and derivatives as well. The only anticipated exception would
be the OMAP2420, which shall
to identify unconfigured bus.
- Status functions now read irqstatus_raw as per TRM guidelines
(except for OMAP243X and OMAP34XX).
- Driver now supports up to I2C5 (OMAP5).
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
---
V5 changes:
- Replaced some printf() with puts().
- Minor formatting touches
Hi Tom,
On 30/05/13 20:07, Tom Rini wrote:
On Thu, May 30, 2013 at 10:37:42AM -0400, Tom Rini wrote:
On Thu, May 30, 2013 at 01:24:42AM +0300, Lubomir Popov wrote:
Tested on OMAP4/5 only, but should work on older OMAPs and
derivatives as well.
- Rewritten i2c_read to operate correctly
Hi Tom,
[snip]
But, crap, breaks am335x_evm (and probably beaglebones, etc). I'll
dig into this more to see if I can spot something obvious tomorrow.
Made it work on the am335x_evm (tested, with AM3359 on board).
Problem was in the new i2c_probe, which on this board is called by
the SPL
to identify unconfigured bus.
- Status functions now read irqstatus_raw as per TRM guidelines
(except for OMAP243X and OMAP34XX).
- Driver now supports up to I2C5 (OMAP5).
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
---
V4 changes:
- New i2c_probe is built unconditionally, old code is removed
Hi Lokesh,
On 30/05/13 16:19, Lokesh Vutla wrote:
From: Balaji T K balaj...@ti.com
add dra mmc pbias support and ldo1 power on
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/include/asm/arch-omap5/omap.h |3 ++-
Hi Tom,
On 30/05/13 17:37, Tom Rini wrote:
On Thu, May 30, 2013 at 01:24:42AM +0300, Lubomir Popov wrote:
Tested on OMAP4/5 only, but should work on older OMAPs and
derivatives as well.
- Rewritten i2c_read to operate correctly with all types of chips
(old function could not read
Hi Tom,
On Thu, May 30, 2013 at 10:37:42AM -0400, Tom Rini wrote:
On Thu, May 30, 2013 at 01:24:42AM +0300, Lubomir Popov wrote:
Tested on OMAP4/5 only, but should work on older OMAPs and
derivatives as well.
- Rewritten i2c_read to operate correctly with all types of chips
(old
Hi Tom,
On Thu, May 30, 2013 at 10:37:42AM -0400, Tom Rini wrote:
On Thu, May 30, 2013 at 01:24:42AM +0300, Lubomir Popov wrote:
Tested on OMAP4/5 only, but should work on older OMAPs and
derivatives as well.
- Rewritten i2c_read to operate correctly with all types of chips
(old
Hi Tom,
On 29/05/13 16:24, Tom Rini wrote:
On 05/29/2013 02:34 AM, Lubomir Popov wrote:
Hi Tom,
On 29.05.2013 01:55, Tom Rini wrote:
On 05/27/2013 02:44 PM, Lubomir Popov wrote:
P.S. I have an updated version of the I2C driver patch, with some
minor
improvements (mainly on identification
).
- Driver now supports up to I2C5 (OMAP5).
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
---
V3 changes:
- Removed old functions and conditional compilation. New functions
are now built unconditionally for all SoCs using this driver. The
only chip that should break is the OMAP2420 dinosaur
(warm) reset at startup.
Add .prm_rsttime init to the ES1.0 struct to fix the issue.
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
---
Based on current u-boot-ti/master; does not apply to
mainline yet.
arch/arm/cpu/armv7/omap5/prcm-regs.c | 1 +
1 file changed, 1 insertion(+)
diff --git
) reset
at startup.
Add .prm_rsttime address init to the ES1.0 struct.
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
---
V2 gives the correct prm_rsttime reg address for ES1.0. Copy-paste
from ES2.0 in V1, sorry.
arch/arm/cpu/armv7/omap5/prcm-regs.c | 1 +
1 file changed, 1 insertion(+)
diff --git
-off-by: Lubomir Popov lpo...@mm-sol.com
---
V2 changes:
- Probe tries to identify misconfigured pads as well.
- Status is retrieved from irqstatus_raw rather than from stat.
- Some minor style format changes.
drivers/i2c/omap24xx_i2c.c | 414 ++---
1 file
Hi Gilles,
On 05/16/2013 10:39 AM, Lubomir Popov wrote:
Hi Gilles,
On 16/05/13 01:31, Gilles Chanteperdrix wrote:
On 05/15/2013 05:55 PM, Lubomir Popov wrote:
Prerequisites: appropriate patches to the USB EHCI and Eth
drivers, and to the OMAP5 clock register definitions.
Hi Lubomir
On 05/18/2013 09:13 PM, Lubomir Popov wrote:
Hi Gilles,
On 05/16/2013 10:39 AM, Lubomir Popov wrote:
Hi Gilles,
On 16/05/13 01:31, Gilles Chanteperdrix wrote:
On 05/15/2013 05:55 PM, Lubomir Popov wrote:
Prerequisites: appropriate patches to the USB EHCI and Eth
drivers
Hi,
On Thursday 16 May 2013 08:59 PM, Tom Rini wrote:
On Thu, May 16, 2013 at 05:56:57PM +0300, Lubomir Popov wrote:
[snip]
The same U-Boot (yesterday's u-boot-ti/master), just configured for
my SOM5_EVB board:
U-Boot SPL 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17)
OMAP5430
Set mux mode to GPIO for the pads used for HSIC USB
device reset.
Remove useless pinmux for USBB1_HSIC - the OMAP5432
does not have this port bonded out.
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
---
I shall again point out that this mux_data.h file comes from the sEVM
board without any
:
On Wed, May 15, 2013 at 06:55:24PM +0300, Lubomir Popov wrote:
Prerequisites: appropriate patches to the USB EHCI and Eth
drivers, and to the OMAP5 clock register definitions.
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
---
Assumption is that this code shall run on TI 750-2628-21X
Hi Gilles,
On 16/05/13 01:31, Gilles Chanteperdrix wrote:
On 05/15/2013 05:55 PM, Lubomir Popov wrote:
Prerequisites: appropriate patches to the USB EHCI and Eth
drivers, and to the OMAP5 clock register definitions.
Hi Lubomir,
I have been trying to get the USB working on omap5 uEVM
Hi Tom,
On 16/05/13 15:28, Tom Rini wrote:
On Thu, May 16, 2013 at 11:23:00AM +0300, Lubomir Popov wrote:
Hi Tom,
Thanks for testing. One more thing needs fixing, my fault.
I forgot that the mux_data.h file comes from the sEVM w/o
any modification. Not only USB shall not work...
Fix
Hi Tom,
On Thu, May 16, 2013 at 05:56:57PM +0300, Lubomir Popov wrote:
[snip]
The same U-Boot (yesterday's u-boot-ti/master), just configured for
my SOM5_EVB board:
U-Boot SPL 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17)
OMAP5430 ES1.0
U-Boot SPL 2013.04-11569-ge3db066-dirty
Hello,
On Wed, May 15, 2013 at 9:51 AM, Lubomir Popov lpo...@mm-sol.com wrote:
Add some useful functions, and the corresponding definitions.
Could you please split these into patches that introduce a function at a
time?
Sure, I could, but for such simple stuff...? Moreover it is currently
On Thu, May 16, 2013 at 2:03 PM, Lubomir Popov lpo...@mm-sol.com wrote:
Well, I needed it when bringing up the board ;) - to validate the
supplies, clocks, etc. Right, this function should be embraced within a
#ifdef CONFIG_PALSMAS_AUDPWR and not compile in the general case (my
code
calling
Hi Sricharan,
On 15/05/13 08:11, Sricharan R wrote:
Hi,
On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote:
On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote:
Hi Tom,
On 14/05/13 17:52, Tom Rini wrote:
On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote:
Hi Tom,
I'm
Hi Sricharan,
On 15/05/13 12:04, Sricharan R wrote:
Hi,
On Wednesday 15 May 2013 01:25 PM, Lubomir Popov wrote:
Hi Sricharan,
On 15/05/13 08:11, Sricharan R wrote:
Hi,
On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote:
On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote:
Hi Tom
1 - 100 of 145 matches
Mail list logo
