Re: [U-Boot] [PATCH V3] cmd_i2c: Provide option for bulk 'i2c write' in one transaction
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 the write
does not come into effect at all, or normal operation of internal circuitry
cannot be guaranteed. The current implementation of the 'i2c write' command
(transfer of multiple bytes from a memory buffer) in fact performs a
separate
transaction for each byte to be written and thus cannot support such types
of
I2C slave devices.
This patch provides an alternative by allowing 'i2c write' to execute the
write transfer of the given number of bytes 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 is implemented as a
run-time
command argument. V1 used conditional compilation through a board header
definition.
common/cmd_i2c.c | 39 ++-
1 file changed, 30 insertions(+), 9 deletions(-)
I should try to apply a patch before saying I tend to accept a patch ;-)
This patch fails again (Sorry Lubomir) ... because in the meantime
this patch from Simon is in mainline:
commit f9a4c2da72d04e13b05deecb800f232d2948eb85
Author: Simon Glass s...@chromium.org
Date: Mon Jan 12 18:02:07 2015 -0700
dm: i2c: Rename driver model I2C functions to permit compatibility
Which introduced dm_i2c_write() ...
What platform are you testing on?
It seems like you could implement this using driver model - just set
or clear the DM_I2C_CHIP_WR_ADDRESS flag.
That would solve the problem of existing platforms, since they could
be tested when converted to driver model.
So what do you think about adjusting this patch to move the '#ifdef
CONFIG_DM_I2C' outside the while loop, and set the flag instead?
Although then your feature would only be available for driver model.
Thinking about this, wouldn;t it be better to add this patch to
this patch?
diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c
index a1a269f..df18b3f 100644
--- a/common/cmd_i2c.c
+++ b/common/cmd_i2c.c
@@ -342,6 +342,7 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[
int ret;
#ifdef CONFIG_DM_I2C
struct udevice *dev;
+ struct dm_i2c_chip *i2c_chip;
#endif
if ((argc 5) || (argc 6))
@@ -377,6 +378,9 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[
ret = i2c_set_chip_offset_len(dev, alen);
if (ret)
return i2c_report_err(ret, I2C_ERR_WRITE);
+ i2c_chip = dev_get_parent_platdata(dev);
+ if (!i2c_chip)
+ return i2c_report_err(ret, I2C_ERR_WRITE);
#endif
if (argc == 6 !strcmp(argv[5], -s)) {
@@ -387,7 +391,8 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[
* into account if linking commands.
*/
#ifdef CONFIG_DM_I2C
- ret = i2c_write(dev, devaddr, memaddr, length);
+ i2c_chip = ~DM_I2C_CHIP_WR_ADDRESS;
+ ret = dm_i2c_write(dev, devaddr, memaddr, length);
#else
ret = i2c_write(chip, devaddr, alen, memaddr, length);
#endif
@@ -400,7 +405,8 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[
*/
while (length-- 0) {
#ifdef CONFIG_DM_I2C
- ret = i2c_write(dev, devaddr++, memaddr++, 1);
+ i2c_chip |= DM_I2C_CHIP_WR_ADDRESS;
+ ret = dm_i2c_write(dev, devaddr++, memaddr++, 1);
#else
ret = i2c_write(chip, devaddr++, alen, memaddr++, 1);
#endif
This looks OK to me; however, since I don't have any DM-enabled
board to test upon, nor currently have any time to test whatever
in general (really sorry), I'm leaving this in your hands, guys.
BR,
Lubo
@Simon: Do I have to check if dev_get_parent_platdata() returns
a pointer?
bye,
Heiko
diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c
index 22db1bb..8d4f5f6 100644
--- a/common/cmd_i2c.c
+++ b/common/cmd_i2c.c
@@ -344,7 +344,7 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[
struct udevice *dev;
#endif
- if (argc != 5)
+ if ((argc 5) || (argc 6))
return cmd_usage(cmdtp);
/*
@@ -367,7 +367,7 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[
return cmd_usage(cmdtp);
/*
-* Length is the number of objects, not number
Re: [U-Boot] [PATCH V3] cmd_i2c: Provide option for bulk 'i2c write' in one transaction
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 of internal circuitry cannot be guaranteed. The current implementation of the 'i2c write' command (transfer of multiple bytes from a memory buffer) in fact performs a separate transaction for each byte to be written and thus cannot support such types of I2C slave devices. This patch provides an alternative by allowing 'i2c write' to execute the write transfer of the given number of bytes 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 is implemented as a run-time command argument. V1 used conditional compilation through a board header definition. common/cmd_i2c.c | 39 ++- 1 file changed, 30 insertions(+), 9 deletions(-) What platform are you testing on? TI OMAP/ARM, in particular the J6Eco EVM (DRA726) where we have a I2C chip that requires this patch for proper operation of some of its functions. It seems like you could implement this using driver model - just set or clear the DM_I2C_CHIP_WR_ADDRESS flag. You are right, I could if I were sure that the DM is/shall be supported by all TI platforms and that I would not break anything now, about which I'm not... :( I'm looping in Tom here. Heiko had asked me just to rebase on current mainline, so that the patch applies cleanly, and that was what I did :) That would solve the problem of existing platforms, since they could be tested when converted to driver model. So what do you think about adjusting this patch to move the '#ifdef CONFIG_DM_I2C' outside the while loop, and set the flag instead? Although then your feature would only be available for driver model. When/if the DM shall be supported by TI platforms. Tom, do we have the DM enabled for any board, so that this could be tested? Regards, Simon Best regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3] cmd_i2c: Provide option for bulk 'i2c write' in one transaction
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 circuitry
cannot be guaranteed. The current implementation of the 'i2c write' command
(transfer of multiple bytes from a memory buffer) in fact performs a separate
transaction for each byte to be written and thus cannot support such types of
I2C slave devices.
This patch provides an alternative by allowing 'i2c write' to execute the
write transfer of the given number of bytes 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 is implemented as a run-time
command argument. V1 used conditional compilation through a board header
definition.
common/cmd_i2c.c | 39 ++-
1 file changed, 30 insertions(+), 9 deletions(-)
diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c
index 22db1bb..8d4f5f6 100644
--- a/common/cmd_i2c.c
+++ b/common/cmd_i2c.c
@@ -344,7 +344,7 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[
struct udevice *dev;
#endif
- if (argc != 5)
+ if ((argc 5) || (argc 6))
return cmd_usage(cmdtp);
/*
@@ -367,7 +367,7 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[
return cmd_usage(cmdtp);
/*
-* Length is the number of objects, not number of bytes.
+* Length is the number of bytes.
*/
length = simple_strtoul(argv[4], NULL, 16);
@@ -379,20 +379,40 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[
return i2c_report_err(ret, I2C_ERR_WRITE);
#endif
- while (length-- 0) {
+ if (argc == 6 !strcmp(argv[5], -s)) {
+ /*
+* Write all bytes in a single I2C transaction. If the target
+* device is an EEPROM, it is your responsibility to not cross
+* a page boundary. No write delay upon completion, take this
+* into account if linking commands.
+*/
#ifdef CONFIG_DM_I2C
- ret = i2c_write(dev, devaddr++, memaddr++, 1);
+ ret = i2c_write(dev, devaddr, memaddr, length);
#else
- ret = i2c_write(chip, devaddr++, alen, memaddr++, 1);
+ ret = i2c_write(chip, devaddr, alen, memaddr, length);
#endif
if (ret)
return i2c_report_err(ret, I2C_ERR_WRITE);
+ } else {
+ /*
+* Repeated addressing - perform length separate
+* write transactions of one byte each
+*/
+ while (length-- 0) {
+#ifdef CONFIG_DM_I2C
+ ret = i2c_write(dev, devaddr++, memaddr++, 1);
+#else
+ ret = i2c_write(chip, devaddr++, alen, memaddr++, 1);
+#endif
+ if (ret)
+ return i2c_report_err(ret, I2C_ERR_WRITE);
/*
* No write delay with FRAM devices.
*/
#if !defined(CONFIG_SYS_I2C_FRAM)
- udelay(11000);
+ udelay(11000);
#endif
+ }
}
return 0;
}
@@ -1823,7 +1843,7 @@ static cmd_tbl_t cmd_i2c_sub[] = {
U_BOOT_CMD_MKENT(nm, 2, 1, do_i2c_nm, , ),
U_BOOT_CMD_MKENT(probe, 0, 1, do_i2c_probe, , ),
U_BOOT_CMD_MKENT(read, 5, 1, do_i2c_read, , ),
- U_BOOT_CMD_MKENT(write, 5, 0, do_i2c_write, , ),
+ U_BOOT_CMD_MKENT(write, 6, 0, do_i2c_write, , ),
#ifdef CONFIG_DM_I2C
U_BOOT_CMD_MKENT(flags, 2, 1, do_i2c_flags, , ),
#endif
@@ -1890,7 +1910,8 @@ static char i2c_help_text[] =
i2c nm chip address[.0, .1, .2] - write to I2C device (constant
address)\n
i2c probe [address] - test for and show device(s) on the I2C bus\n
i2c read chip address[.0, .1, .2] length memaddress - read to memory\n
- i2c write memaddress chip address[.0, .1, .2] length - write memory to
i2c\n
+ i2c write memaddress chip address[.0, .1, .2] length [-s] - write
memory\n
+ to I2C; the -s option selects bulk write in a single
transaction\n
#ifdef CONFIG_DM_I2C
i2c flags chip [flags] - set or get chip flags\n
#endif
@@ -1902,7 +1923,7 @@ static char i2c_help_text[] =
#endif
U_BOOT_CMD(
- i2c, 6, 1, do_i2c,
+ i2c, 7, 1, do_i2c,
I2C sub-system,
i2c_help_text
);
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd_i2c: Provide option for bulk 'i2c write' in one transaction
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 circuitry
cannot be guaranteed. The current implementation of the 'i2c write' command
(transfer of multiple bytes from a memory buffer) in fact performs a separate
transaction for each byte to be written and thus cannot support such types of
I2C slave devices.
This patch provides an alternative by allowing 'i2c write' to execute the
write transfer of the given number of bytes 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(-)
Could you rebase your patch against current mainline, please?
As we have now DM in i2c subsystem your patch does not apply clean
anymore ... thanks!
It looks like you are referring V1 of the patch here. The correct
version is V2 (http://patchwork.ozlabs.org/patch/415117/). If it
doesn't apply as well, I shall try to find some time to fix it.
Thanks,
Lubo
bye,
Heiko
diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c
index 3a75f94..7116458 100644
--- a/common/cmd_i2c.c
+++ b/common/cmd_i2c.c
@@ -280,10 +280,22 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag,
int argc, char * const argv[
return cmd_usage(cmdtp);
/*
- * Length is the number of objects, not number of bytes.
+ * Length is the number of bytes.
*/
length = simple_strtoul(argv[4], NULL, 16);
+#if defined(CONFIG_SYS_I2C_BULK_WRITE)
+/*
+ * Write all bytes in a single I2C transaction. If the target
+ * device is an EEPROM, it is your responsibility to not cross
+ * a page bounady.
+ */
+if (i2c_write(chip, devaddr, alen, memaddr, length) != 0) {
+puts(Error writing to the chip.\n);
+return 1;
+}
+#else
+/* Perform length separate write transactions of one byte each */
while (length-- 0) {
if (i2c_write(chip, devaddr++, alen, memaddr++, 1) != 0) {
puts(Error writing to the chip.\n);
@@ -296,6 +308,7 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[
udelay(11000);
#endif
}
+#endif
return 0;
}
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd_i2c: Provide option for bulk 'i2c write' in one transaction
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 the write
does not come into effect at all, or normal operation of internal circuitry
cannot be guaranteed. The current implementation of the 'i2c write' command
(transfer of multiple bytes from a memory buffer) in fact performs a
separate
transaction for each byte to be written and thus cannot support such types
of
I2C slave devices.
This patch provides an alternative by allowing 'i2c write' to execute the
write transfer of the given number of bytes 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(-)
Could you rebase your patch against current mainline, please?
As we have now DM in i2c subsystem your patch does not apply clean
anymore ... thanks!
It looks like you are referring V1 of the patch here. The correct
version is V2 (http://patchwork.ozlabs.org/patch/415117/). If it
doesn't apply as well, I shall try to find some time to fix it.
Sorry, was the wrong EMail I replied ... but the v2 does not
apply to current mainline. If you can fix it, that would be great.
OK. Do you have a deadline to finish the I2C updates? I'm really
very busy right now and am not sure if I shall manage with this
before the end of the week, but can try...
Regards,
Lubo
Thanks!
bye,
Heiko
Thanks,
Lubo
bye,
Heiko
diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c
index 3a75f94..7116458 100644
--- a/common/cmd_i2c.c
+++ b/common/cmd_i2c.c
@@ -280,10 +280,22 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag,
int argc, char * const argv[
return cmd_usage(cmdtp);
/*
- * Length is the number of objects, not number of bytes.
+ * Length is the number of bytes.
*/
length = simple_strtoul(argv[4], NULL, 16);
+#if defined(CONFIG_SYS_I2C_BULK_WRITE)
+ /*
+ * Write all bytes in a single I2C transaction. If the target
+ * device is an EEPROM, it is your responsibility to not cross
+ * a page bounady.
+ */
+ if (i2c_write(chip, devaddr, alen, memaddr, length) != 0) {
+ puts(Error writing to the chip.\n);
+ return 1;
+ }
+#else
+ /* Perform length separate write transactions of one byte each */
while (length-- 0) {
if (i2c_write(chip, devaddr++, alen, memaddr++, 1) !=
0) {
puts(Error writing to the chip.\n);
@@ -296,6 +308,7 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag,
int argc, char * const argv[
udelay(11000);
#endif
}
+#endif
return 0;
}
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: OMAP5: DRA7xx: Add support for power rail grouping
On the DRA72x (J6Eco) EVM one PMIC SMPS is powering three SoC
core rails. This concept of using one SMPS to supply multiple
core domains (in various, although limited combinations, per
primary device use case) has now become common and is used by
many customer J6/J6Eco designs; it is supported by a number of
corresponding PMIC OTP versions.
This patch implements correct operation of the core voltages
scaling routine by ensuring that each SMPS that is supplying
more than one domain shall be written only once, and with the
highest voltage of those fused in the SoC (or of those defined
in the corresponding header if fuse read is disabled or fails)
for the power rails belonging to the group.
The patch also replaces some PMIC-related magic numbers with
the appropriate definitions. The default OPP_NOM voltages for
the DRA7xx SoCs are updated as well, per the latest DMs.
Signed-off-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 insertions(+), 28 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 8e7411d..b036cbc 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -437,12 +437,15 @@ void do_scale_vcore(u32 vcore_reg, u32 volt_mv, struct
pmic_data *pmic)
{
u32 offset_code;
u32 offset = volt_mv;
+#ifndefCONFIG_DRA7XX
int ret = 0;
+#endif
if (!volt_mv)
return;
pmic-pmic_bus_init();
+#ifndefCONFIG_DRA7XX
/* See if we can first get the GPIO if needed */
if (pmic-gpio_en)
ret = gpio_request(pmic-gpio, PMIC_GPIO);
@@ -456,7 +459,7 @@ void do_scale_vcore(u32 vcore_reg, u32 volt_mv, struct
pmic_data *pmic)
/* Pull the GPIO low to select SET0 register, while we program SET1 */
if (pmic-gpio_en)
gpio_direction_output(pmic-gpio, 0);
-
+#endif
/* convert to uV for better accuracy in the calculations */
offset *= 1000;
@@ -467,9 +470,10 @@ void do_scale_vcore(u32 vcore_reg, u32 volt_mv, struct
pmic_data *pmic)
if (pmic-pmic_write(pmic-i2c_slave_addr, vcore_reg, offset_code))
printf(Scaling voltage failed for 0x%x\n, vcore_reg);
-
+#ifndefCONFIG_DRA7XX
if (pmic-gpio_en)
gpio_direction_output(pmic-gpio, 1);
+#endif
}
static u32 optimize_vcore_voltage(struct volts const *v)
@@ -505,13 +509,79 @@ static u32 optimize_vcore_voltage(struct volts const *v)
}
/*
- * Setup the voltages for vdd_mpu, vdd_core, and vdd_iva
- * We set the maximum voltages allowed here because Smart-Reflex is not
- * enabled in bootloader. Voltage initialization in the kernel will set
- * these to the nominal values after enabling Smart-Reflex
+ * Setup the voltages for the main SoC core power domains.
+ * We start with the maximum voltages allowed here, as set in the corresponding
+ * vcores_data struct, and then scale (usually down) to the fused values that
+ * are retrieved from the SoC. The scaling happens only if the efuse.reg fields
+ * are initialised.
+ * Rail grouping is supported for the DRA7xx SoCs only, therefore the code is
+ * compiled conditionally. Note that the new code writes the scaled (or zeroed)
+ * values back to the vcores_data struct for eventual reuse. Zero values mean
+ * that the corresponding rails are not controlled separately, and are not sent
+ * to the PMIC.
*/
void scale_vcores(struct vcores_data const *vcores)
{
+#if defined(CONFIG_DRA7XX)
+ int i;
+ struct volts *pv = (struct volts *)vcores;
+ struct volts *px;
+
+ for (i=0; i(sizeof(struct vcores_data)/sizeof(struct volts)); i++) {
+ debug(%d - , pv-value);
+ if (pv-value) {
+ /* Handle non-empty members only */
+ pv-value = optimize_vcore_voltage(pv);
+ px = (struct volts *)vcores;
+ while (px pv) {
+ /*
+* Scan already handled non-empty members to see
+* if we have a group and find the max voltage,
+* which is set to the first occurance of the
+* particular SMPS; the other group voltages are
+* zeroed.
+*/
+ if (px-value) {
+ if ((pv-pmic-i2c_slave_addr ==
+px-pmic-i2c_slave_addr)
+ (pv-addr == px-addr
Re: [U-Boot] [PATCH] ARM: OMAP5: DRA7xx: Enable I2C4 and I2C5 usage on the J6Eco EVM
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 member .cm_l4per_i2c5_clkctrl is not initialized, and 2) a 'data abort' exception shall happen if access to I2C5 is tried due to lack of the functional clock. Best regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd_i2c: Provide option for bulk 'i2c write' in one transaction
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 of internal circuitry
cannot be guaranteed. The current implementation of the 'i2c write' command
(transfer of multiple bytes from a memory buffer) in fact performs a separate
transaction for each byte to be written and thus cannot support such types of
I2C slave devices.
This patch provides an alternative by allowing 'i2c write' to execute the
write transfer of the given number of bytes 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/common/cmd_i2c.c
index 3a75f94..7116458 100644
--- a/common/cmd_i2c.c
+++ b/common/cmd_i2c.c
@@ -280,10 +280,22 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag,
int argc, char * const argv[
return cmd_usage(cmdtp);
/*
-* Length is the number of objects, not number of bytes.
+* Length is the number of bytes.
*/
length = simple_strtoul(argv[4], NULL, 16);
+#if defined(CONFIG_SYS_I2C_BULK_WRITE)
+ /*
+* Write all bytes in a single I2C transaction. If the target
+* device is an EEPROM, it is your responsibility to not cross
+* a page bounady.
+*/
+ if (i2c_write(chip, devaddr, alen, memaddr, length) != 0) {
+ puts(Error writing to the chip.\n);
+ return 1;
+ }
+#else
+ /* Perform length separate write transactions of one byte each */
while (length-- 0) {
if (i2c_write(chip, devaddr++, alen, memaddr++, 1) != 0) {
puts(Error writing to the chip.\n);
@@ -296,6 +308,7 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[
udelay(11000);
#endif
This should really be an option/flag on the command. We might want to
do different things depending on the situation.
Agree. I thought about this initially, even about adding a separate command,
but then decided that the human device using 'i2c write' with or without the
config option would be intelligent enough to know what is being needed and
done. From a chip compatibility perspective this is not an issue, since for
byte-wise transfers the 'i2c mw' and 'i2c mm' commands still do exist. So I
went the easy way :-).
In fact with driver model's I2C implementation, currently in review,
this logic of splitting things up can be handled in the uclass layer:
http://patchwork.ozlabs.org/patch/414066/
Right, in the DM context a command line option would be the better solution.
I shall see to revising the patch in this respect.
Regards,
Simon
Best regards,
Lubo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] cmd_i2c: Provide option for bulk 'i2c write' in one transaction
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 circuitry
cannot be guaranteed. The current implementation of the 'i2c write' command
(transfer of multiple bytes from a memory buffer) in fact performs a separate
transaction for each byte to be written and thus cannot support such types of
I2C slave devices.
This patch provides an alternative by allowing 'i2c write' to execute the
write transfer of the given number of bytes 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 and shall better fit into the new I2C DM (thanks to Simon for
the hint). V1 used conditional compilation through a board header definition.
common/cmd_i2c.c | 35 +--
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c
index c266b88..5cb7dca 100644
--- a/common/cmd_i2c.c
+++ b/common/cmd_i2c.c
@@ -270,7 +270,7 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[
uintdevaddr, alen, length;
u_char *memaddr;
- if (argc != 5)
+ if ((argc 5) || (argc 6))
return cmd_usage(cmdtp);
/*
@@ -293,20 +293,34 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[
return cmd_usage(cmdtp);
/*
-* Length is the number of objects, not number of bytes.
+* Length is the number of bytes.
*/
length = simple_strtoul(argv[4], NULL, 16);
-
- while (length-- 0) {
- if (i2c_write(chip, devaddr++, alen, memaddr++, 1) != 0) {
+
+ if (argc == 6 !strcmp(argv[5], -s)) {
+ /*
+* Write all bytes in a single I2C transaction. If the target
+* device is an EEPROM, it is your responsibility to not cross
+* a page boundary. No write delay upon completion, take this
+* into account if linking commands.
+*/
+ if (i2c_write(chip, devaddr, alen, memaddr, length) != 0)
return i2c_report_err(-1, I2C_ERR_WRITE);
- }
+ } else {
+ /*
+* Repeated addressing - perform length separate
+* write transactions of one byte each
+*/
+ 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.
*/
#if !defined(CONFIG_SYS_I2C_FRAM)
- udelay(11000);
+ udelay(11000);
#endif
+ }
}
return 0;
}
@@ -1559,7 +1573,7 @@ static cmd_tbl_t cmd_i2c_sub[] = {
U_BOOT_CMD_MKENT(nm, 2, 1, do_i2c_nm, , ),
U_BOOT_CMD_MKENT(probe, 0, 1, do_i2c_probe, , ),
U_BOOT_CMD_MKENT(read, 5, 1, do_i2c_read, , ),
- U_BOOT_CMD_MKENT(write, 5, 0, do_i2c_write, , ),
+ U_BOOT_CMD_MKENT(write, 6, 0, do_i2c_write, , ),
U_BOOT_CMD_MKENT(reset, 0, 1, do_i2c_reset, , ),
#if defined(CONFIG_CMD_SDRAM)
U_BOOT_CMD_MKENT(sdram, 1, 1, do_sdram, , ),
@@ -1623,7 +1637,8 @@ static char i2c_help_text[] =
i2c nm chip address[.0, .1, .2] - write to I2C device (constant
address)\n
i2c probe [address] - test for and show device(s) on the I2C bus\n
i2c read chip address[.0, .1, .2] length memaddress - read to memory
\n
- i2c write memaddress chip address[.0, .1, .2] length - write memory to
i2c\n
+ i2c write memaddress chip address[.0, .1, .2] length [-s] - write
memory\n
+ to I2C; the -s option selects bulk write in a single
transaction\n
i2c reset - re-init the I2C Controller\n
#if defined(CONFIG_CMD_SDRAM)
i2c sdram chip - print SDRAM configuration information\n
@@ -1632,7 +1647,7 @@ static char i2c_help_text[] =
#endif
U_BOOT_CMD(
- i2c, 6, 1, do_i2c,
+ i2c, 7, 1, do_i2c,
I2C sub-system,
i2c_help_text
);
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] cmd_i2c: Provide option for bulk 'i2c write' in one transaction
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?
#if !defined(CONFIG_SYS_I2C_FRAM)
- udelay(11000);
+ udelay(11000);
#endif
+ }
[snip]
Which indent do you mean? The udelay() is within the while loop, so it should.
The
comment above your note - I kept it as is, aligned with the #if/#endif.
Regards,
Lubo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cmd_i2c: Provide option for bulk 'i2c write' in one transaction
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 circuitry
cannot be guaranteed. The current implementation of the 'i2c write' command
(transfer of multiple bytes from a memory buffer) in fact performs a separate
transaction for each byte to be written and thus cannot support such types of
I2C slave devices.
This patch provides an alternative by allowing 'i2c write' to execute the
write transfer of the given number of bytes 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/common/cmd_i2c.c
index 3a75f94..7116458 100644
--- a/common/cmd_i2c.c
+++ b/common/cmd_i2c.c
@@ -280,10 +280,22 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[
return cmd_usage(cmdtp);
/*
-* Length is the number of objects, not number of bytes.
+* Length is the number of bytes.
*/
length = simple_strtoul(argv[4], NULL, 16);
+#if defined(CONFIG_SYS_I2C_BULK_WRITE)
+ /*
+* Write all bytes in a single I2C transaction. If the target
+* device is an EEPROM, it is your responsibility to not cross
+* a page bounady.
+*/
+ if (i2c_write(chip, devaddr, alen, memaddr, length) != 0) {
+ puts(Error writing to the chip.\n);
+ return 1;
+ }
+#else
+ /* Perform length separate write transactions of one byte each */
while (length-- 0) {
if (i2c_write(chip, devaddr++, alen, memaddr++, 1) != 0) {
puts(Error writing to the chip.\n);
@@ -296,6 +308,7 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[
udelay(11000);
#endif
}
+#endif
return 0;
}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: OMAP5: DRA7xx: Enable I2C4 and I2C5 usage on the J6Eco EVM
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 buses. For I2C5 to work, the 'ARM: OMAP5: DRA7xx: Enable I2C5 operation' patch 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 OK, but what's the usecase for enabling these in U-Boot? Are we using things on these buses? Both I2C4 and I2C5 are routed to expansion connectors on the J6Eco board. If a customer has some add-on hardware with I2C devices attached through these connectors, it seems useful to have the buses functional for bring- up/debug. Moreover, the board itself has two devices on I2C5, one of them being a GPIO expander driving some system configuration signals (e.g. for override of the boot settings), and being able to control it could be useful as well. Best regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: OMAP5: DRA7xx: Enable I2C5 operation
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 Popov l-po...@ti.com
---
arch/arm/cpu/armv7/omap5/hw_data.c |9 +
arch/arm/cpu/armv7/omap5/prcm-regs.c |4
arch/arm/include/asm/omap_common.h |4
3 files changed, 17 insertions(+)
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 0257383..5f7b392 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -515,6 +515,10 @@ void enable_basic_clocks(void)
void enable_basic_uboot_clocks(void)
{
u32 const clk_domains_essential[] = {
+#ifdef CONFIG_DRA7XX
+ /* Needed for I2C5 operation */
+ (*prcm)-cm_ipu_clkstctrl,
+#endif
0
};
@@ -528,7 +532,12 @@ void enable_basic_uboot_clocks(void)
(*prcm)-cm_l4per_i2c2_clkctrl,
(*prcm)-cm_l4per_i2c3_clkctrl,
(*prcm)-cm_l4per_i2c4_clkctrl,
+#ifdef CONFIG_DRA7XX
+ /* I2C5 is in the IPU clock domain on the DRA7xx */
+ (*prcm)-cm_ipu_i2c5_clkctrl,
+#else
(*prcm)-cm_l4per_i2c5_clkctrl,
+#endif
(*prcm)-cm_l3init_hsusbhost_clkctrl,
(*prcm)-cm_l3init_fsusb_clkctrl,
0
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index ff08ef4..1337198 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -808,6 +808,10 @@ struct prcm_regs const dra7xx_prcm = {
/* cm1.dsp */
.cm_dsp_clkstctrl = 0x4a005400,
.cm_dsp_dsp_clkctrl = 0x4a005420,
+
+ /* cm1.ipu */
+ .cm_ipu_clkstctrl = 0x4a005540,
+ .cm_ipu_i2c5_clkctrl= 0x4a005578,
/* prm irqstatus regs */
.prm_irqstatus_mpu_2= 0x4ae06014,
diff --git a/arch/arm/include/asm/omap_common.h
b/arch/arm/include/asm/omap_common.h
index 1838234..962c8a5 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -80,6 +80,10 @@ struct prcm_regs {
u32 cm_dsp_clkstctrl;
u32 cm_dsp_dsp_clkctrl;
+ /* cm1.ipu */
+ u32 cm_ipu_clkstctrl;
+ u32 cm_ipu_i2c5_clkctrl;
+
/* cm1.abe */
u32 cm1_abe_clkstctrl;
u32 cm1_abe_l4abe_clkctrl;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: OMAP5: DRA7xx: Enable I2C4 and I2C5 usage on the J6Eco EVM
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 buses.
For I2C5 to work, the 'ARM: OMAP5: DRA7xx: Enable I2C5 operation'
patch 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/dra7xx/evm.c
index 37df7b2..25dae8e 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -124,6 +124,13 @@ void set_muxconf_regs_essential(void)
core_padconf_array_essential,
sizeof(core_padconf_array_essential) /
sizeof(struct pad_conf_entry));
+
+ if (omap_revision() == DRA722_ES1_0) {
+ do_set_mux32((*ctrl)-control_padconf_core_base,
+core_padconf_array_j6ecoevm,
+sizeof(core_padconf_array_j6ecoevm) /
+sizeof(struct pad_conf_entry));
+ }
}
#if !defined(CONFIG_SPL_BUILD) defined(CONFIG_GENERIC_MMC)
diff --git a/board/ti/dra7xx/mux_data.h b/board/ti/dra7xx/mux_data.h
index 4824077..f155f65 100644
--- a/board/ti/dra7xx/mux_data.h
+++ b/board/ti/dra7xx/mux_data.h
@@ -141,4 +141,12 @@ const struct pad_conf_entry core_padconf_array_essential[]
= {
{USB2_DRVVBUS, (M0 | IEN | FSC) },
{SPI1_CS1, (PEN | IDIS | M14) },
};
+
+const struct pad_conf_entry core_padconf_array_j6ecoevm[] = {
+ {MCASP1_AXR0, (IEN | PTU | PDIS | M10)},/* I2C5_SDA */
+ {MCASP1_AXR1, (IEN | PTU | PDIS | M10)},/* I2C5_SCL */
+
+ {MCASP4_ACLKX, (IEN | PTU | PDIS | M4)},/* I2C4_SDA */
+ {MCASP4_FSX, (IEN | PTU | PDIS | M4)}, /* I2C4_SCL */
+};
#endif /* _MUX_DATA_DRA7XX_H_ */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mmc: Cosmetic fix for nicer, aligned device list printout
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 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 44a4feb..e0ea833 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1401,8 +1401,11 @@ void print_mmc_devices(char separator)
printf(%s: %d, m-cfg-name, m-block_dev.dev);
- if (entry-next != mmc_devices)
- printf(%c , separator);
+ if (entry-next != mmc_devices) {
+ printf(%c, separator);
+ if (separator != '\n')
+ puts ( );
+ }
}
printf(\n);
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: OMAP5: DRA7xx: Enable 8-bit eMMC access on the dra7xx_evm
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/dra7xx_evm.h +++ b/include/configs/dra7xx_evm.h @@ -50,6 +50,7 @@ #define CONFIG_EFI_PARTITION #define CONFIG_PARTITION_UUIDS #define CONFIG_CMD_PART +#define CONFIG_HSMMC2_8BIT /* CPSW Ethernet */ #define CONFIG_CMD_NET /* 'bootp' and 'tftp' */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: OMAP5: DRA7xx: Fix misleading comments in mux_data.h
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/mux_data.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/ti/dra7xx/mux_data.h b/board/ti/dra7xx/mux_data.h
index 7276014..4824077 100644
--- a/board/ti/dra7xx/mux_data.h
+++ b/board/ti/dra7xx/mux_data.h
@@ -130,8 +130,8 @@ const struct pad_conf_entry core_padconf_array_essential[]
= {
{GPMC_A13, (IEN | PDIS | M1)}, /* QSPI1_RTCLK */
{GPMC_A14, (IEN | PDIS | M1)}, /* QSPI1_D[3] */
{GPMC_A15, (IEN | PDIS | M1)}, /* QSPI1_D[2] */
- {GPMC_A16, (IEN | PDIS | M1)}, /* QSPI1_D[1] */
- {GPMC_A17, (IEN | PDIS | M1)}, /* QSPI1_D[0] */
+ {GPMC_A16, (IEN | PDIS | M1)}, /* QSPI1_D[0] */
+ {GPMC_A17, (IEN | PDIS | M1)}, /* QSPI1_D[1] */
{GPMC_A18, (M1)}, /* QSPI1_SCLK */
{GPMC_A3, (IEN | PDIS | M1)}, /* QSPI1_CS2 */
{GPMC_A4, (IEN | PDIS | M1)}, /* QSPI1_CS3 */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 0/2] OMAP4/5: Add alternative method for HSIC USB devices reset
This patch introduces an alternative method for resetting HSIC-attached USB devices on OMAP4/5, needed for working around the fail to connect with some types. The solution implemented by Dan Murphy for the OMAP5432 uEVM (reset via a callback in the board file, invoked from within usb_hub.c) does work for that board, but is proven to fail for a custom OMAP5430 design. Moreover, the uEVM should not be taken for a OMAP5 golden standard due to a hardware limitation: power switches for the two downstream ports of the USB3503A hub (such switches must be controlled by the hub) have been omitted, and VBUS is always present on the sockets whenever DC input power is applied to the board. This could be one of the possible reasons for U-Boot not being able to detect some particular flash drives (that otherwise work correctly on other OMAP4/5 boards), as well as for some known Linux issues. The proposed patch provides an option for individual reset of HSIC-connected USB devices, with configurable reset hold and delay times, all enabled by defines in the board header only. This option is activated if at least one CONFIG_OMAP_HSIC_PORTx_RESET_GPIO has been defined - then a weak dummy function in ehci-hcd.c (in the USB_PORT_FEAT_POWER feature set by ehci_submit_root()) shall be overridden by a callback in ehci-omap.c that shall do the actual device reset for the specified ports. No changes to the board .c file are required. If desired, Dan's method may be preserved and shall co-exist for other ports if an overriding function is present in the board file. The patch also fixes HSIC operation on all OMAP5-ES1.0 USB ports. It has to be noted that this patch proposes a strict differentiation between PHYs and HSIC devices, which seems reasonable - a HSIC-connected device is actually a permanently attached USB slave, while a PHY is just a hardware extension of the host port, and handling them in the same manner is not appropriate. Tested on the OMAP5432 uEVM, as well as on a custom OMAP5430 board (with two HSIC devices - USB4640 combo hub and LAN9730 Ethernet) and on a custom 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 drivers/usb/host/ehci-omap.c | 174 +- include/configs/omap5_uevm.h | 13 +++- 4 files changed, 182 insertions(+), 22 deletions(-) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 1/2] ARM: OMAP4/5: Add alternative method for HSIC USB devices reset
Add option for individual reset of HSIC-connected USB devices by the
ehci-hcd.c driver upon applying port power, with per-device configurable
reset hold and delay times. This may replace the reset functionality via
usb_hub.c and board file (which does not work on some boards).
Make HSIC work 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/usb/host/ehci-hcd.c
index 8bd1eb8..47b4097 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -119,6 +119,12 @@ static struct descriptor {
#define ehci_is_TDI() (0)
#endif
+/* OMAP HSIC workaround option: */
+__weak void omap_ehci_hsic_reset_device(int port)
+{
+ return;
+}
+
int __ehci_get_port_speed(struct ehci_hcor *hcor, uint32_t reg)
{
return PORTSC_PSPD(reg);
@@ -803,6 +809,15 @@ ehci_submit_root(struct usb_device *dev, unsigned long
pipe, void *buffer,
if (HCS_PPC(ehci_readl(ctrl-hccr-cr_hcsparams))) {
reg |= EHCI_PS_PP;
ehci_writel(status_reg, reg);
+ /*
+* OMAP4/5: Reset device for 'fail to connect'
+* workaround. Weak function, actual reset
+* should happen in ehci-omap.c and only if we
+* have defined HSIC devices (in the board file)
+* that we want to reset at this moment.
+*/
+ omap_ehci_hsic_reset_device(
+ le16_to_cpu(req-index));
}
break;
case USB_PORT_FEAT_RESET:
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 1b215c2..071739d 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -7,6 +7,13 @@
* Sunil Kumar sunilsain...@gmail.com
* Shashi Ranjan shashiranjanmc...@gmail.com
*
+ * (C) Copyright 2013 Lubomir Popov, MM Solutions lpo...@mm-sol.com
+ * - Add option for individual reset of HSIC-connected USB devices by the
+ * ehci-hcd.c driver upon applying port power, with per-device configurable
+ * reset hold and delay times. This may replace the reset functionality via
+ * usb_hub.c and board file;
+ * - Make HSIC work on all OMAP5430-ES1.0 ports;
+ * - Add explanatory comments where appropriate.
*
* SPDX-License-Identifier:GPL-2.0+
*/
@@ -26,6 +33,8 @@ static struct omap_uhh *const uhh = (struct omap_uhh
*)OMAP_UHH_BASE;
static struct omap_usbtll *const usbtll = (struct omap_usbtll
*)OMAP_USBTLL_BASE;
static struct omap_ehci *const ehci = (struct omap_ehci *)OMAP_EHCI_BASE;
+static struct omap_usbhs_board_data *usbhs_bdp = NULL;
+
static int omap_uhh_reset(void)
{
int timeout = 0;
@@ -106,7 +115,7 @@ static void omap_usbhs_hsic_init(int port)
writel(reg, usbtll-channel_conf + port);
}
-#ifdef CONFIG_USB_ULPI
+#if defined(CONFIG_USB_ULPI) defined(CONFIG_USB_ULPI_VIEWPORT_OMAP)
static void omap_ehci_soft_phy_reset(int port)
{
struct ulpi_viewport ulpi_vp;
@@ -158,10 +167,141 @@ static inline void omap_ehci_phy_reset(int on, int delay)
#define omap_ehci_phy_reset(on, delay) do {} while (0)
#endif
+/*
+ * Individual HSIC USB device reset to fix 'fail to connect' for some devices.
+ * Note that a HSIC-connected device is actually a permanently attached USB
+ * slave, while a PHY is just a hardware extension of the host port, and
+ * handling them in the same manner is not appropriate.
+ * In order to invoke this feature, define CONFIG_OMAP_HSIC_PORTx_RESET_GPIO
+ * in the board header (where x is the port number with HSIC-attached device
+ * that we want to reset via this method, and the value is the number of the
+ * particular GPIO) - the real functions shall then build and override the
+ * __weak dummy in ehci-hcd.c that is called upon applying port power. The
+ * active reset hold time, as well as the delay after release of reset, are
+ * configurable per device (port) via CONFIG_OMAP_PORTx_RST_HOLD_US and
+ * CONFIG_OMAP_PORTx_DLY_AFTER_US.
+ *
+ * Applicable to OMAP4/5 only (except for the OMAP4430, where HSIC is not
+ * functional). Valid HSIC ports are:
+ * OMAP4460/70: 1, 2
+ * OMAP5430:1, 2, 3
+ * OMAP5432:2, 3
+ */
+#if defined(CONFIG_OMAP_HSIC_PORT1_RESET_GPIO) || \
+defined(CONFIG_OMAP_HSIC_PORT2_RESET_GPIO) || \
+defined(CONFIG_OMAP_HSIC_PORT3_RESET_GPIO)
+/* Should not be called for non-HSIC ports */
+static void omap_ehci_hsic_reset(int port, int on, int delay)
+{
+ debug(HSIC device reset: port %d, reset %s, delay %d us\n,
+ port
[U-Boot] [RFC PATCH 2/2] ARM: omap5_uevm: Example usage of alternative HSIC USB device reset
This patch demonstrates the usage of the alternative method for HSIC
devices reset (via the ehci-hcd and omap-ehci drivers, where this
method is implemented through a separate patch; must be applied prior
to this one). Board functionality is not altered; a minor improvement
is the removal 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 changed, 12 insertions(+), 3 deletions(-)
diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
index af854da..cae9fd8 100644
--- a/board/ti/omap5_uevm/evm.c
+++ b/board/ti/omap5_uevm/evm.c
@@ -210,6 +210,7 @@ int ehci_hcd_stop(void)
return ret;
}
+#if !defined(CONFIG_OMAP_HSIC_PORT3_RESET_GPIO)
void usb_hub_reset_devices(int port)
{
/* The LAN9730 needs to be reset after the port power has been set. */
@@ -220,6 +221,7 @@ void usb_hub_reset_devices(int port)
}
}
#endif
+#endif
#ifdef CONFIG_USB_XHCI_OMAP
/**
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index 2f128b8..96b5f23 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -50,10 +50,17 @@
#define CONFIG_USB_EHCI_OMAP
#define CONFIG_USB_STORAGE
#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3
-#define CONFIG_EHCI_HCD_INIT_AFTER_RESET
+/*#define CONFIG_EHCI_HCD_INIT_AFTER_RESET*/
-#define CONFIG_OMAP_EHCI_PHY2_RESET_GPIO 80
-#define CONFIG_OMAP_EHCI_PHY3_RESET_GPIO 79
+/* No ULPI PHYs on this board */
+/*#define CONFIG_OMAP_EHCI_PHY2_RESET_GPIO 80*/
+/*#define CONFIG_OMAP_EHCI_PHY3_RESET_GPIO 79*/
+/*
+ * Due to HSIC connect ussues with some devices, a reset is required
+ * upon applying port power. A GPIO is needed per HSIC device:
+ */
+#define CONFIG_OMAP_HSIC_PORT2_RESET_GPIO 80 /* Hub */
+#define CONFIG_OMAP_HSIC_PORT3_RESET_GPIO 79 /* Ethernet Ctrlr */
/* Enabled commands */
#define CONFIG_CMD_DHCP/* DHCP Support */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: omap5_uevm: Enable 8-bit eMMC access
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/configs/omap5_uevm.h index 96b5f23..3c479db 100644 --- a/include/configs/omap5_uevm.h +++ b/include/configs/omap5_uevm.h @@ -36,6 +36,7 @@ #define CONFIG_EFI_PARTITION #define CONFIG_PARTITION_UUIDS #define CONFIG_CMD_PART +#define CONFIG_HSMMC2_8BIT /* Required support for the TCA642X GPIO we have on the uEVM */ #define CONFIG_TCA642X -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH V2 1/2] ARM: OMAP4/5: Add alternative method for HSIC USB devices reset
Add option for individual reset of HSIC-connected USB devices by the
ehci-hcd.c driver upon applying port power, with per-device configurable
reset hold and delay times. This may replace the reset functionality via
usb_hub.c and board file (which does not work on some boards).
Make HSIC work 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 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 8bd1eb8..47b4097 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -119,6 +119,12 @@ static struct descriptor {
#define ehci_is_TDI() (0)
#endif
+/* OMAP HSIC workaround option: */
+__weak void omap_ehci_hsic_reset_device(int port)
+{
+ return;
+}
+
int __ehci_get_port_speed(struct ehci_hcor *hcor, uint32_t reg)
{
return PORTSC_PSPD(reg);
@@ -803,6 +809,15 @@ ehci_submit_root(struct usb_device *dev, unsigned long
pipe, void *buffer,
if (HCS_PPC(ehci_readl(ctrl-hccr-cr_hcsparams))) {
reg |= EHCI_PS_PP;
ehci_writel(status_reg, reg);
+ /*
+* OMAP4/5: Reset device for 'fail to connect'
+* workaround. Weak function, actual reset
+* should happen in ehci-omap.c and only if we
+* have defined HSIC devices (in the board file)
+* that we want to reset at this moment.
+*/
+ omap_ehci_hsic_reset_device(
+ le16_to_cpu(req-index));
}
break;
case USB_PORT_FEAT_RESET:
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 1b215c2..071739d 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -7,6 +7,13 @@
* Sunil Kumar sunilsain...@gmail.com
* Shashi Ranjan shashiranjanmc...@gmail.com
*
+ * (C) Copyright 2013 Lubomir Popov, MM Solutions lpo...@mm-sol.com
+ * - Add option for individual reset of HSIC-connected USB devices by the
+ * ehci-hcd.c driver upon applying port power, with per-device configurable
+ * reset hold and delay times. This may replace the reset functionality via
+ * usb_hub.c and board file;
+ * - Make HSIC work on all OMAP5430-ES1.0 ports;
+ * - Add explanatory comments where appropriate.
*
* SPDX-License-Identifier:GPL-2.0+
*/
@@ -26,6 +33,8 @@ static struct omap_uhh *const uhh = (struct omap_uhh
*)OMAP_UHH_BASE;
static struct omap_usbtll *const usbtll = (struct omap_usbtll
*)OMAP_USBTLL_BASE;
static struct omap_ehci *const ehci = (struct omap_ehci *)OMAP_EHCI_BASE;
+static struct omap_usbhs_board_data *usbhs_bdp = NULL;
+
static int omap_uhh_reset(void)
{
int timeout = 0;
@@ -106,7 +115,7 @@ static void omap_usbhs_hsic_init(int port)
writel(reg, usbtll-channel_conf + port);
}
-#ifdef CONFIG_USB_ULPI
+#if defined(CONFIG_USB_ULPI) defined(CONFIG_USB_ULPI_VIEWPORT_OMAP)
static void omap_ehci_soft_phy_reset(int port)
{
struct ulpi_viewport ulpi_vp;
@@ -158,10 +167,141 @@ static inline void omap_ehci_phy_reset(int on, int delay)
#define omap_ehci_phy_reset(on, delay) do {} while (0)
#endif
+/*
+ * Individual HSIC USB device reset to fix 'fail to connect' for some devices.
+ * Note that a HSIC-connected device is actually a permanently attached USB
+ * slave, while a PHY is just a hardware extension of the host port, and
+ * handling them in the same manner is not appropriate.
+ * In order to invoke this feature, define CONFIG_OMAP_HSIC_PORTx_RESET_GPIO
+ * in the board header (where x is the port number with HSIC-attached device
+ * that we want to reset via this method, and the value is the number of the
+ * particular GPIO) - the real functions shall then build and override the
+ * __weak dummy in ehci-hcd.c that is called upon applying port power. The
+ * active reset hold time, as well as the delay after release of reset, are
+ * configurable per device (port) via CONFIG_OMAP_PORTx_RST_HOLD_US and
+ * CONFIG_OMAP_PORTx_DLY_AFTER_US.
+ *
+ * Applicable to OMAP4/5 only (except for the OMAP4430, where HSIC is not
+ * functional). Valid HSIC ports are:
+ * OMAP4460/70: 1, 2
+ * OMAP5430:1, 2, 3
+ * OMAP5432:2, 3
+ */
+#if defined(CONFIG_OMAP_HSIC_PORT1_RESET_GPIO) || \
+defined(CONFIG_OMAP_HSIC_PORT2_RESET_GPIO) || \
+defined(CONFIG_OMAP_HSIC_PORT3_RESET_GPIO)
+/* Should not be called for non-HSIC ports */
+static void omap_ehci_hsic_reset(int port, int on, int delay
[U-Boot] [RFC PATCH V3 1/2] ARM: OMAP4/5: Add alternative method for HSIC USB devices reset
Add option for individual reset of HSIC-connected USB devices by the
ehci-hcd.c driver upon applying port power, with per-device configurable
reset hold and delay times. This may replace the reset functionality via
usb_hub.c and board file (which does not work on some boards).
Make HSIC work 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 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 8bd1eb8..47b4097 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -119,6 +119,12 @@ static struct descriptor {
#define ehci_is_TDI() (0)
#endif
+/* OMAP HSIC workaround option: */
+__weak void omap_ehci_hsic_reset_device(int port)
+{
+ return;
+}
+
int __ehci_get_port_speed(struct ehci_hcor *hcor, uint32_t reg)
{
return PORTSC_PSPD(reg);
@@ -803,6 +809,15 @@ ehci_submit_root(struct usb_device *dev, unsigned long
pipe, void *buffer,
if (HCS_PPC(ehci_readl(ctrl-hccr-cr_hcsparams))) {
reg |= EHCI_PS_PP;
ehci_writel(status_reg, reg);
+ /*
+* OMAP4/5: Reset device for 'fail to connect'
+* workaround. Weak function, actual reset
+* should happen in ehci-omap.c and only if we
+* have defined HSIC devices (in the board file)
+* that we want to reset at this moment.
+*/
+ omap_ehci_hsic_reset_device(
+ le16_to_cpu(req-index));
}
break;
case USB_PORT_FEAT_RESET:
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 1b215c2..071739d 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -7,6 +7,13 @@
* Sunil Kumar sunilsain...@gmail.com
* Shashi Ranjan shashiranjanmc...@gmail.com
*
+ * (C) Copyright 2013 Lubomir Popov, MM Solutions lpo...@mm-sol.com
+ * - Add option for individual reset of HSIC-connected USB devices by the
+ * ehci-hcd.c driver upon applying port power, with per-device configurable
+ * reset hold and delay times. This may replace the reset functionality via
+ * usb_hub.c and board file;
+ * - Make HSIC work on all OMAP5430-ES1.0 ports;
+ * - Add explanatory comments where appropriate.
*
* SPDX-License-Identifier:GPL-2.0+
*/
@@ -26,6 +33,8 @@ static struct omap_uhh *const uhh = (struct omap_uhh
*)OMAP_UHH_BASE;
static struct omap_usbtll *const usbtll = (struct omap_usbtll
*)OMAP_USBTLL_BASE;
static struct omap_ehci *const ehci = (struct omap_ehci *)OMAP_EHCI_BASE;
+static struct omap_usbhs_board_data *usbhs_bdp;
+
static int omap_uhh_reset(void)
{
int timeout = 0;
@@ -106,7 +115,7 @@ static void omap_usbhs_hsic_init(int port)
writel(reg, usbtll-channel_conf + port);
}
-#ifdef CONFIG_USB_ULPI
+#if defined(CONFIG_USB_ULPI) defined(CONFIG_USB_ULPI_VIEWPORT_OMAP)
static void omap_ehci_soft_phy_reset(int port)
{
struct ulpi_viewport ulpi_vp;
@@ -158,10 +167,141 @@ static inline void omap_ehci_phy_reset(int on, int delay)
#define omap_ehci_phy_reset(on, delay) do {} while (0)
#endif
+/*
+ * Individual HSIC USB device reset to fix 'fail to connect' for some devices.
+ * Note that a HSIC-connected device is actually a permanently attached USB
+ * slave, while a PHY is just a hardware extension of the host port, and
+ * handling them in the same manner is not appropriate.
+ * In order to invoke this feature, define CONFIG_OMAP_HSIC_PORTx_RESET_GPIO
+ * in the board header (where x is the port number with HSIC-attached device
+ * that we want to reset via this method, and the value is the number of the
+ * particular GPIO) - the real functions shall then build and override the
+ * __weak dummy in ehci-hcd.c that is called upon applying port power. The
+ * active reset hold time, as well as the delay after release of reset, are
+ * configurable per device (port) via CONFIG_OMAP_PORTx_RST_HOLD_US and
+ * CONFIG_OMAP_PORTx_DLY_AFTER_US.
+ *
+ * Applicable to OMAP4/5 only (except for the OMAP4430, where HSIC is not
+ * functional). Valid HSIC ports are:
+ * OMAP4460/70: 1, 2
+ * OMAP5430:1, 2, 3
+ * OMAP5432:2, 3
+ */
+#ifdefined(CONFIG_OMAP_HSIC_PORT1_RESET_GPIO) || \
+ defined(CONFIG_OMAP_HSIC_PORT2_RESET_GPIO) || \
+ defined(CONFIG_OMAP_HSIC_PORT3_RESET_GPIO)
+/* Should not be called for non-HSIC ports */
+static void omap_ehci_hsic_reset(int port, int on, int delay)
+{
+ debug
[U-Boot] [RFC PATCH V4 1/2] ARM: OMAP4/5: Add alternative method for HSIC USB devices reset
Add option for individual reset of HSIC-connected USB devices by the
ehci-hcd.c driver upon applying port power, with per-device configurable
reset hold and delay times. This may replace the reset functionality via
usb_hub.c and board file (which does not work on some boards).
Make HSIC work 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, 170 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 8bd1eb8..17efb69 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -119,6 +119,12 @@ static struct descriptor {
#define ehci_is_TDI() (0)
#endif
+/* OMAP HSIC workaround option: */
+__weak void omap_ehci_hsic_reset_device(int port)
+{
+ return;
+}
+
int __ehci_get_port_speed(struct ehci_hcor *hcor, uint32_t reg)
{
return PORTSC_PSPD(reg);
@@ -803,6 +809,15 @@ ehci_submit_root(struct usb_device *dev, unsigned long
pipe, void *buffer,
if (HCS_PPC(ehci_readl(ctrl-hccr-cr_hcsparams))) {
reg |= EHCI_PS_PP;
ehci_writel(status_reg, reg);
+ /*
+* OMAP4/5: Reset device for 'fail to connect'
+* workaround. Weak function, actual reset
+* should happen in ehci-omap.c and only if we
+* have defined HSIC devices (in the board file)
+* that we want to reset at this moment.
+*/
+ omap_ehci_hsic_reset_device(
+ le16_to_cpu(req-index));
}
break;
case USB_PORT_FEAT_RESET:
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 1b215c2..d3609a4 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -7,6 +7,13 @@
* Sunil Kumar sunilsain...@gmail.com
* Shashi Ranjan shashiranjanmc...@gmail.com
*
+ * (C) Copyright 2013 Lubomir Popov, MM Solutions lpo...@mm-sol.com
+ * - Add option for individual reset of HSIC-connected USB devices by the
+ * ehci-hcd.c driver upon applying port power, with per-device configurable
+ * reset hold and delay times. This may replace the reset functionality via
+ * usb_hub.c and board file;
+ * - Make HSIC work on all OMAP5430-ES1.0 ports;
+ * - Add explanatory comments where appropriate.
*
* SPDX-License-Identifier:GPL-2.0+
*/
@@ -26,6 +33,8 @@ static struct omap_uhh *const uhh = (struct omap_uhh
*)OMAP_UHH_BASE;
static struct omap_usbtll *const usbtll = (struct omap_usbtll
*)OMAP_USBTLL_BASE;
static struct omap_ehci *const ehci = (struct omap_ehci *)OMAP_EHCI_BASE;
+static struct omap_usbhs_board_data *usbhs_bdp;
+
static int omap_uhh_reset(void)
{
int timeout = 0;
@@ -106,7 +115,7 @@ static void omap_usbhs_hsic_init(int port)
writel(reg, usbtll-channel_conf + port);
}
-#ifdef CONFIG_USB_ULPI
+#if defined(CONFIG_USB_ULPI) defined(CONFIG_USB_ULPI_VIEWPORT_OMAP)
static void omap_ehci_soft_phy_reset(int port)
{
struct ulpi_viewport ulpi_vp;
@@ -158,10 +167,141 @@ static inline void omap_ehci_phy_reset(int on, int delay)
#define omap_ehci_phy_reset(on, delay) do {} while (0)
#endif
+/*
+ * Individual HSIC USB device reset to fix 'fail to connect' for some devices.
+ * Note that a HSIC-connected device is actually a permanently attached USB
+ * slave, while a PHY is just a hardware extension of the host port, and
+ * handling them in the same manner is not appropriate.
+ * In order to invoke this feature, define CONFIG_OMAP_HSIC_PORTx_RESET_GPIO
+ * in the board header (where x is the port number with HSIC-attached device
+ * that we want to reset via this method, and the value is the number of the
+ * particular GPIO) - the real functions shall then build and override the
+ * __weak dummy in ehci-hcd.c that is called upon applying port power. The
+ * active reset hold time, as well as the delay after release of reset, are
+ * configurable per device (port) via CONFIG_OMAP_PORTx_RST_HOLD_US and
+ * CONFIG_OMAP_PORTx_DLY_AFTER_US.
+ *
+ * Applicable to OMAP4/5 only (except for the OMAP4430, where HSIC is not
+ * functional). Valid HSIC ports are:
+ * OMAP4460/70: 1, 2
+ * OMAP5430:1, 2, 3
+ * OMAP5432:2, 3
+ */
+#ifdefined(CONFIG_OMAP_HSIC_PORT1_RESET_GPIO) || \
+ defined(CONFIG_OMAP_HSIC_PORT2_RESET_GPIO) || \
+ defined(CONFIG_OMAP_HSIC_PORT3_RESET_GPIO)
+/* Should not be called for non-HSIC ports */
+static void omap_ehci_hsic_reset(int port, int on, int delay
Re: [U-Boot] ARM: OMAP4: Fix bug in omap4470_volts struct
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 to voltage selection codes. Signed-off-by: Lubomir Popov l-po...@ti.com Applied to u-boot-ti/master, thanks! But I have a follow-up question, should we be using the TWL6032 support I also just pushed in this case? Sorry, but I'm currently unsubscripted from the ML. Could you please providea link to Oleg's patches so that I can take a look? Thanks, Lubo P.S. Regarding Nikita's fix for OMAP3 I2C, don't you think it should be applied as well? Or it is up to Heiko? (http://patchwork.ozlabs.org/patch/294957/) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] arm: omap: i2c: don't zero cnt in i2c_write
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 to the following advisory which apears in multiple erratas for OMAP3 SoCs (OMAP35xx, DM37xx), as well as OMAP4430 TRM: Advisory: I2C Module Does Not Allow 0-Byte Data Requests Details: When configured as the master, the I2C module does not allow 0-byte data transfers. Note: Programming I2Ci.I2C_CNT[15:0]: DCOUNT = 0 will cause undefined behavior. Workaround(s): No workaround. Do not use 0-byte data requests. The writes in question are unnecessary from a functional point of view. Most of them are done after I/O has finished, and the only one that preceds I/O (in i2c_probe()) is also unnecessary because a stop bit is sent before actual data transmission takes place. Therefore, remove all writes that zero the cnt 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 instances of writew(0, i2c_base-cnt) instead of just the one in i2c_write (following a test of V1 by Thomas Petazzoni). Tested-by: Lubomir Popov lpo...@mm-sol.com In addition to the OMAP5430/32 tests performed last week, tested today on OMAP4 (4430/60/70) and on AM3359. Thus tests have covered OMAP4/5- compatible I2C IPs with revnb_lo=[0x000a to 0x000c] (revnb_hi is 0x5040 for all those IPs). May I know on top of which tree,tag you are trying this patch ? I tried OMAP4 on top of v2014.01-rc1, but I am not able to boot. I applied this patch and still not able to boot. There is a mail thread going on, on this topic. So I just wanted to know that I am not missing very obvious. For most boards (the OMAP5432 uEVM, our OMAP5430 board, the 4460 Pandaboard ES, the AM335x General Purpose EVM and the AM335x Starter Kit) this was a version of the master branch that I cloned on Nov. 12. See dump below (with some debug prints added to display the I2C core revision numbers): U-Boot SPL 2013.10-00339-gd7adce9-dirty (Dec 03 2013 - 09:31:33) OMAP5432 ES2.0 SPL: Please implement spl_start_uboot() for your board SPL: Direct Linux boot not active! reading u-boot.img reading u-boot.img U-Boot 2013.10-00339-gd7adce9-dirty (Dec 03 2013 - 09:31:33) CPU : OMAP5432 ES2.0 Board: OMAP5432 uEVM I2C: I2C_REVNB_LO: 0x000c I2C_REVNB_HI: 0x5040 ready DRAM: 2 GiB I2C_REVNB_LO: 0x000c I2C_REVNB_HI: 0x5040 I2C_REVNB_LO: 0x000c I2C_REVNB_HI: 0x5040 MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment I2C_REVNB_LO: 0x000c I2C_REVNB_HI: 0x5040 Net: No ethernet found. Hit any key to stop autoboot: 0 U-Boot# For our OMAP4 board (on which I tested the OMAP4430 ES2.1, OMAP4460 ES1.0 and ES1.1, and OMAP4470 ES1.0, by means of TI Blaze/Tablet processor cards) I used a 2013.04 version of U-Boot, on which I developed the new I2C driver back then and on which the submitted driver patches were based (the driver was mainlined in 2013.07, AFAIR); in this version I also have working support for OMAP4470/TWL6032 (not mainlined). I did so because the 2013.10 version used for the other boards won't boot on our OMAP4, and I didn't have time to investigate why (it did boot on the Panda ES though). The reason to not use the current master branch is ridiculous - my workplace is for some months now within the TI intranet, and since about mid November, when some network infrastructure reorg happened, the TI proxy blocks my access to any git repo. Because my current work is not related to software, I haven't actively opted for granting access until yesterday, and am now waiting. In summary, what I have done is essentially to confirm that removing all writes of a 0-byte length to the i2c_cnt register (which is _needed_ to fix the OMAP3 problem) does not affect operation on OMAP4/5-compatible I2C IPs. I have not applied Nikita's fix as a patch, but have manually commented out those lines in both U-Boot versions used for the test. This is probably against the formal rules, but I stand behind the statement that functionally all is OK. On which board did you fail to boot OMAP4? Isn't this a strange coincidence, aren't we having a regression...? :-( -- Regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] arm: omap: i2c: don't zero cnt in i2c_write
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 to the following advisory which apears in multiple erratas for OMAP3 SoCs (OMAP35xx, DM37xx), as well as OMAP4430 TRM: Advisory: I2C Module Does Not Allow 0-Byte Data Requests Details: When configured as the master, the I2C module does not allow 0-byte data transfers. Note: Programming I2Ci.I2C_CNT[15:0]: DCOUNT = 0 will cause undefined behavior. Workaround(s): No workaround. Do not use 0-byte data requests. The writes in question are unnecessary from a functional point of view. Most of them are done after I/O has finished, and the only one that preceds I/O (in i2c_probe()) is also unnecessary because a stop bit is sent before actual data transmission takes place. Therefore, remove all writes that zero the cnt 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 instances of writew(0, i2c_base-cnt) instead of just the one in i2c_write (following a test of V1 by Thomas Petazzoni). Tested-by: Lubomir Popov lpo...@mm-sol.com In addition to the OMAP5430/32 tests performed last week, tested today on OMAP4 (4430/60/70) and on AM3359. Thus tests have covered OMAP4/5- compatible I2C IPs with revnb_lo=[0x000a to 0x000c] (revnb_hi is 0x5040 for all those IPs). -- Regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] arm: omap: i2c: don't zero cnt in i2c_write
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 to the following advisory which apears in multiple erratas for OMAP3 SoCs (OMAP35xx, DM37xx), as well as OMAP4430 TRM: Advisory: I2C Module Does Not Allow 0-Byte Data Requests Details: When configured as the master, the I2C module does not allow 0-byte data transfers. Note: Programming I2Ci.I2C_CNT[15:0]: DCOUNT = 0 will cause undefined behavior. Workaround(s): No workaround. Do not use 0-byte data requests. The writes in question are unnecessary from a functional point of view. Most of them are done after I/O has finished, and the only one that preceds I/O (in i2c_probe()) is also unnecessary because a stop bit is sent before actual data transmission takes place. Therefore, remove all writes that zero the cnt 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 instances of writew(0, i2c_base-cnt) instead of just the one in i2c_write (following a test of V1 by Thomas Petazzoni). Tested today on a OMAP5432uEVM and on a custom OMAP5430 board. All is OK. Shall test on OMAP4 next week. -- Regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3 i2c issues on IGEP, u-boot 2013.10
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 on which I'm seeing this. So indeed, a OMAP3-based board is affected. But maybe I misunderstood your question. Oops, sorry, bad question :) Anybody knows if other OMAP3-based boards are affected for this issue ? Our boards were also affected by this, and I managed to track the problem down to the zeroing of cnt register at the end of write, which was not present in the original version of the driver and appears to be triggering an issue that is mentioned in OMAP3 errata. I just posted a patch to address this problem. You can find it here: http://patchwork.ozlabs.org/patch/294593/ Thanks for this patch. Unfortunately, I've applied it, and it doesn't fix the problem for me. I still have those I2C issues (did 3 boots of the IGEP boards, two of the boot failed with an endless stream of i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10)) message. Thanks, Thomas The zeroing of the cnt register also happens in other places in the driver, and it is entirely possible that they should be removed for OMAP3s as well. In my patch I removed it only for i2c_write() because the original driver also zeroed the cnt register in I/O functions- except in i2c_write(), and I decided to follow the original driver's lead. What happens if you remove all the lines that zero the cnt register? I think you are on the right track. Tom R, I guess I have been right back in spring when proposing this to be a driver for OMAP4+ only. Best regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3 i2c issues on IGEP, u-boot 2013.10
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 question: my paragraph above mentions the IGEP board as being the platform on which I'm seeing this. So indeed, a OMAP3-based board is affected. But maybe I misunderstood your question. Oops, sorry, bad question :) Anybody knows if other OMAP3-based boards are affected for this issue ? Our boards were also affected by this, and I managed to track the problem down to the zeroing of cnt register at the end of write, which was not present in the original version of the driver and appears to be triggering an issue that is mentioned in OMAP3 errata. I just posted a patch to address this problem. You can find it here: http://patchwork.ozlabs.org/patch/294593/ Thanks for this patch. Unfortunately, I've applied it, and it doesn't fix the problem for me. I still have those I2C issues (did 3 boots of the IGEP boards, two of the boot failed with an endless stream of i2c_read (addr phase): pads on bus 0 probably not configured (status=0x10)) message. Thanks, Thomas The zeroing of the cnt register also happens in other places in the driver, and it is entirely possible that they should be removed for OMAP3s as well. In my patch I removed it only for i2c_write() because the original driver also zeroed the cnt register in I/O functions- except in i2c_write(), and I decided to follow the original driver's lead. What happens if you remove all the lines that zero the cnt register? I think you are on the right track. Tom R, I guess I have been right back in spring when proposing this to be a driver for OMAP4+ only. Well, the kernel driver handles omap1/2/3/4 so the problem is we aren't respecting (and tracking) the differences like we need to. I do not want to if at all possible have an omap3 driver (since we dropped omap24xx and will be dropping the last omap1 shortly) and an omap4+ driver that're pretty close, with just a few differences. Generally you are right; the problem is that it is very hard, if ever possible, to test some piece of software on all targets that it would be run on, and account for every fancy silicon errata. Regarding this particular issue, the clearing of the byte count reg is actually not needed at the end of every transaction. I guess it is some jic legacy from older times, and I also kept it (even excessively, it tuns out ;-) ) for some level of backward compatibility. Shall try to find some time next week to test the driver on all OMAP-based boards that I can gather with this operation removed from all functions and see what happens. Thanks again everyone for catching and fixing this. Regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: OMAP4: Fix bug in omap4470_volts struct
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 | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap4/hw_data.c
b/arch/arm/cpu/armv7/omap4/hw_data.c
index 6a225c8..1b2f439 100644
--- a/arch/arm/cpu/armv7/omap4/hw_data.c
+++ b/arch/arm/cpu/armv7/omap4/hw_data.c
@@ -288,17 +288,21 @@ struct vcores_data omap4460_volts = {
.mm.pmic = twl6030,
};
+/*
+ * Take closest integer part of the mV value corresponding to a TWL6032 SMPS
+ * voltage selection code. Aligned with OMAP4470 ES1.0 OCA V.0.7.
+ */
struct vcores_data omap4470_volts = {
-.mpu.value = 1200,
+.mpu.value = 1202,
.mpu.addr = SMPS_REG_ADDR_SMPS1,
.mpu.pmic = twl6030,
.core.value = 1126,
-.core.addr = SMPS_REG_ADDR_SMPS1,
+.core.addr = SMPS_REG_ADDR_SMPS2,
.core.pmic = twl6030,
-.mm.value = 1137,
-.mm.addr = SMPS_REG_ADDR_SMPS1,
+.mm.value = 1139,
+.mm.addr = SMPS_REG_ADDR_SMPS5,
.mm.pmic = twl6030,
};
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] A question about unconfigured pads check in omap24xx_i2c
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 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 peculiar to me since the meaning of I2C_STAT_XRDY is
that new data is requested for transmission. Why is that
indication that
the bus is not padconf'd for I2C?
Hi Nikita,
This has been empirically confirmed on OMAP4 and OMAP5. When the pads
are not
configured, the I2C controller is actually disconnected from the bus.
The clock
input for its state machine has to come from the bus however due to
stretching
etc., although it is internally generated. So actually nothing changes
within
the controller after a transaction attempt is made, and it keeps its
initial
state with XRDY set only (ready to accept transmit data). I use
this as an
indicator. Not perfect, but works in most cases.
Regards,
Lubo
Thanks for the quick reply.
The reason I stumbled across this is that this check hasn't been
working
well on our OMAP3 based devices. Some I2C transactions work fine, but
some of them fail this check in the address phase, especially if the
I2C
transactions happen in quick successions.
You mean that you occasionally get this error on an otherwise properly
configured and working bus, right?
Yes.
Does this happen with particular
slave devices only, or randomly? And is it happening in the SPL, or in
regular U-Boot?
It happens in U-Boot when communicating with the PMIC (TPS65930),
but like I said, it worked in the driver's previous version, on the
same module.
We did not have any I2C issues
with the previous driver, and while this behavior is symptomatic of
timing issues playing around with the delays didn't help.
Which delays did you modify? Did you try to increase
I2C_WAIT/I2C_TIMEOUT?
I tried to increase both I2C_WAIT and I2C_TIMEOUT, and place my own
delays as well.
I was wondering if you might have some insights as to what may cause
the
controller to behave this way other than unconfigured pads?
Unfortunately I don't have any hands-on experience with OMAP3 (apart
from
some very quick testing on a AM3359 derivative), and cannot guarantee
that
the I2C controller IP on OMAP3 is absolutely the same as on OMAP4/5
(most
probably it isn't; shall check this on Monday). Anyway, if everything
else
is OK (muxmode/pad config, pull-ups, power, etc.), the only reasonable
explanation would be that there is not enough time for the controller to
update its status register under certain conditions, and these would be
either a slower clock rate (that makes byte transmission time come close
to the timeout), or clock stretching by some slaves; btw, the latter
seems probable, judging from your words that this happens in the address
phase, when some devices could take longer to prepare for action, and
they
do this by stretching the clock. That is why I'm asking if you tried to
increase I2C_TIMEOUT. Did you do any measurements on the bus to see
if all
is OK and the clock rate is right, and if it gets stretched by some
slaves?
I believe I found the cause of the problem. In the new version of the
driver the following line was added to the exit sequence of i2c_write:
writew(0, i2c_base-cnt);
Removing this line solved the problem (module has been doing I2C
transactions for the last 16 hours or so without failing), and I
believe the reason has to do with Advisory 1.2 in the DM3730 errata:
Advisory 1.2I2C Module Does Not Allow 0-Byte Data Requests
Revision(s) Affected1.2, 1.1 and 1.0
DetailsWhen configured as the master, the I2C module
does not allow 0-byte data transfers.
Programming I2Ci.I2C_CNT[15:0]: DCOUNT = 0 will
cause undefined behavior.
Workaround(s)There is no workaround for this issue. Do not
use 0-byte data requests.
While the mentioned write is done at the end of i2c_write, perhaps the
driver's MO still triggers this issue. It certainly is plausible
that this line was missing from the old i2c_write exit sequence on
purpose, and not by accident (i2c_read, i2c_probe, and i2c_init all
had it in the old driver).
Many thanks for catching this. Feel free to post a patch.
Lubo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] A question about unconfigured pads check in omap24xx_i2c
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) {
printf(unconfigured pads\n);
return -1;
}
This check seems peculiar to me since the meaning of I2C_STAT_XRDY is
that new data is requested for transmission. Why is that indication that
the bus is not padconf'd for I2C?
Hi Nikita,
This has been empirically confirmed on OMAP4 and OMAP5. When the pads
are not
configured, the I2C controller is actually disconnected from the bus.
The clock
input for its state machine has to come from the bus however due to
stretching
etc., although it is internally generated. So actually nothing changes
within
the controller after a transaction attempt is made, and it keeps its
initial
state with XRDY set only (ready to accept transmit data). I use this as an
indicator. Not perfect, but works in most cases.
Regards,
Lubo
Thanks for the quick reply.
The reason I stumbled across this is that this check hasn't been working
well on our OMAP3 based devices. Some I2C transactions work fine, but
some of them fail this check in the address phase, especially if the I2C
transactions happen in quick successions.
You mean that you occasionally get this error on an otherwise properly
configured and working bus, right? Does this happen with particular
slave devices only, or randomly? And is it happening in the SPL, or in
regular U-Boot?
We did not have any I2C issues
with the previous driver, and while this behavior is symptomatic of
timing issues playing around with the delays didn't help.
Which delays did you modify? Did you try to increase I2C_WAIT/I2C_TIMEOUT?
I was wondering if you might have some insights as to what may cause the
controller to behave this way other than unconfigured pads?
Unfortunately I don't have any hands-on experience with OMAP3 (apart from
some very quick testing on a AM3359 derivative), and cannot guarantee that
the I2C controller IP on OMAP3 is absolutely the same as on OMAP4/5 (most
probably it isn't; shall check this on Monday). Anyway, if everything else
is OK (muxmode/pad config, pull-ups, power, etc.), the only reasonable
explanation would be that there is not enough time for the controller to
update its status register under certain conditions, and these would be
either a slower clock rate (that makes byte transmission time come close
to the timeout), or clock stretching by some slaves; btw, the latter
seems probable, judging from your words that this happens in the address
phase, when some devices could take longer to prepare for action, and they
do this by stretching the clock. That is why I'm asking if you tried to
increase I2C_TIMEOUT. Did you do any measurements on the bus to see if all
is OK and the clock rate is right, and if it gets stretched by some slaves?
Regards,
Lubo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] A question about unconfigured pads check in omap24xx_i2c
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/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 peculiar to me since the meaning of I2C_STAT_XRDY is
that new data is requested for transmission. Why is that
indication that
the bus is not padconf'd for I2C?
Hi Nikita,
This has been empirically confirmed on OMAP4 and OMAP5. When the
pads are not
configured, the I2C controller is actually disconnected from the
bus. The clock
input for its state machine has to come from the bus however due to
stretching
etc., although it is internally generated. So actually nothing
changes within
the controller after a transaction attempt is made, and it keeps
its initial
state with XRDY set only (ready to accept transmit data). I use
this as an
indicator. Not perfect, but works in most cases.
Thanks for this explanation! Maybe we can document this somewhere in
the code?
bye,
Heiko
You are right, it would be good to document it. Unfortunately I have not
been on the U-Boot wave for some months now due to very heavy engagement
with other stuff; have even unsubscribed from the list. I think however
that in order to give definite statements and improve the driver, a new
round of experiments has to be made to cover the two major types of
design
flaws (software and/or hardware): incorrect pad configuration, and
missing
pullups (internal or external). I wrote this driver more that 6
months ago
with the goal to have something working properly (the then existing
one was,
mildly put, not good), and this detection is just a bonus side effect.
In summary, the professional approach would require some more effort,
which
I'm not sure when I could afford. Otherwise, if just an explanation
for the
current algo is to be given, no problem - I can just add some comments.
I vote for the professional approach ;-) But if you have no time, and
can just send a comment for the current state (maybe with a short
summary,
what should be done) I am fine with this too!
OK, shall see to the easy way first - just add some comments, sometime
next week.
But, no promises ;-)
Lubo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] A question about unconfigured pads check in omap24xx_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 peculiar to me since the meaning of I2C_STAT_XRDY is
that new data is requested for transmission. Why is that indication that
the bus is not padconf'd for I2C?
Hi Nikita,
This has been empirically confirmed on OMAP4 and OMAP5. When the pads
are not
configured, the I2C controller is actually disconnected from the bus.
The clock
input for its state machine has to come from the bus however due to
stretching
etc., although it is internally generated. So actually nothing changes
within
the controller after a transaction attempt is made, and it keeps its initial
state with XRDY set only (ready to accept transmit data). I use this as an
indicator. Not perfect, but works in most cases.
Regards,
Lubo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] A question about unconfigured pads check in omap24xx_i2c
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 in the form of
if (status == I2C_STAT_XRDY) {
printf(unconfigured pads\n);
return -1;
}
This check seems peculiar to me since the meaning of I2C_STAT_XRDY is
that new data is requested for transmission. Why is that indication
that
the bus is not padconf'd for I2C?
Hi Nikita,
This has been empirically confirmed on OMAP4 and OMAP5. When the pads
are not
configured, the I2C controller is actually disconnected from the bus.
The clock
input for its state machine has to come from the bus however due to
stretching
etc., although it is internally generated. So actually nothing
changes within
the controller after a transaction attempt is made, and it keeps its
initial
state with XRDY set only (ready to accept transmit data). I use this
as an
indicator. Not perfect, but works in most cases.
Thanks for this explanation! Maybe we can document this somewhere in
the code?
bye,
Heiko
You are right, it would be good to document it. Unfortunately I have not
been on the U-Boot wave for some months now due to very heavy engagement
with other stuff; have even unsubscribed from the list. I think however
that in order to give definite statements and improve the driver, a new
round of experiments has to be made to cover the two major types of design
flaws (software and/or hardware): incorrect pad configuration, and missing
pullups (internal or external). I wrote this driver more that 6 months ago
with the goal to have something working properly (the then existing one was,
mildly put, not good), and this detection is just a bonus side effect.
In summary, the professional approach would require some more effort, which
I'm not sure when I could afford. Otherwise, if just an explanation for the
current algo is to be given, no problem - I can just add some comments.
What do you think?
Regards,
Lubo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] should print_mmc_devices() not add an extraneous blank between devices?
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');
which reasonably defines a newline as a separator, but then there's
this in drivers/mmc/mmc.c:
list_for_each(entry, mmc_devices) {
m = list_entry(entry, struct mmc, link);
printf(%s: %d, m-name, m-block_dev.dev);
if (entry-next != mmc_devices)
printf(%c , separator);
}
where that loop inserts the separator *and* a blank. is that
deliberate? it just looks weird.
I have used to fix this as follows on some older U-Boot versions:
if (entry-next != mmc_devices) {
printf(%c, separator);
if (separator != '\n')
puts ( );
}
But as this is just cosmetics, never bothered to submit a patch, nor
am fixing it anymore locally. If you are a style perfectionist, do
submit one... ;)
Best regards,
Lubomir
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: OMAP: Enable 8-bit eMMC access for OMAP4/5/DRA7xx
Enable 8-bit host capability for HSMMC2 and/or HSMMC3. CONFIG_HSMMC2_8BIT
(for OMAP4/5/DRA7xx) and/or CONFIG_HSMMC3_8BIT (for DRA7xx only) must be
defined in the board header if an 8-bit eMMC device is connected to the
corresponding port.
Fix the No status update error that appeared for 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
---
Tested on a custom OMAP5430 board with a SanDisk 8 GB eMMC, and on a TI
750-2172 Processor Board (with OMAP4460 ES1.1 and a 32 GB SanDisk eMMC),
mounted on a custom main board. Actual performance gain is negligible as
compared to 4-bit mode (about 2 ms faster FAT loading for a 4 MB image on
the 4460, that is in the range of 1%), but the advantage is that the eMMC
interface can be electrically validated in U-Boot.
drivers/mmc/omap_hsmmc.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 975b2c5..08e2c8b 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -376,6 +376,7 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
}
writel(cmd-cmdarg, mmc_base-arg);
+ udelay(20); /* To fix No status update error on eMMC */
writel((cmd-cmdidx 24) | flags, mmc_base-cmd);
start = get_timer(0);
@@ -480,7 +481,7 @@ static int mmc_write_data(struct hsmmc *mmc_base, const
char *buf,
unsigned int count;
/*
-* Start Polled Read
+* Start Polled Write
*/
count = (size MMCSD_SECTOR_SIZE) ? MMCSD_SECTOR_SIZE : size;
count /= 4;
@@ -586,6 +587,8 @@ int omap_mmc_init(int dev_index, uint host_caps_mask, uint
f_max, int cd_gpio,
{
struct mmc *mmc = hsmmc_dev[dev_index];
struct omap_hsmmc_data *priv_data = hsmmc_dev_data[dev_index];
+ uint host_caps_val = MMC_MODE_4BIT | MMC_MODE_HS_52MHz | MMC_MODE_HS |
+MMC_MODE_HC;
sprintf(mmc-name, OMAP SD/MMC);
mmc-send_cmd = mmc_send_cmd;
@@ -600,11 +603,20 @@ int omap_mmc_init(int dev_index, uint host_caps_mask,
uint f_max, int cd_gpio,
#ifdef OMAP_HSMMC2_BASE
case 1:
priv_data-base_addr = (struct hsmmc *)OMAP_HSMMC2_BASE;
+#if (defined(CONFIG_OMAP44XX) || defined(CONFIG_OMAP54XX) || \
+ defined(CONFIG_DRA7XX)) defined(CONFIG_HSMMC2_8BIT)
+ /* Enable 8-bit interface for eMMC on OMAP4/5 or DRA7XX */
+ host_caps_val |= MMC_MODE_8BIT;
+#endif
break;
#endif
#ifdef OMAP_HSMMC3_BASE
case 2:
priv_data-base_addr = (struct hsmmc *)OMAP_HSMMC3_BASE;
+#if defined(CONFIG_DRA7XX) defined(CONFIG_HSMMC3_8BIT)
+ /* Enable 8-bit interface for eMMC on DRA7XX */
+ host_caps_val |= MMC_MODE_8BIT;
+#endif
break;
#endif
default:
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] ARM: OMAP: Enable 8-bit eMMC access for OMAP4/5/DRA7xx
Enable 8-bit host capability for HSMMC2 and/or HSMMC3. CONFIG_HSMMC2_8BIT
(for OMAP4/5/DRA7xx) and/or CONFIG_HSMMC3_8BIT (for DRA7xx only) must be
defined in the board header if an 8-bit eMMC device is connected to the
corresponding port.
Fix the No status update error that appeared for 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; tests were
performed with U-Boot 2013.04, where it was patched initially).
Tested on a custom OMAP5430 board with a SanDisk 8 GB eMMC, and on a TI
750-2172 Processor Board (with OMAP4460 ES1.1 and a 32 GB SanDisk eMMC),
mounted on a custom main board. Actual performance gain is negligible as
compared to 4-bit mode (about 2 ms faster FAT loading for a 4 MB image on
the 4460, that is in the range of 1%), but the advantage is that the eMMC
interface can be electrically validated in U-Boot.
drivers/mmc/omap_hsmmc.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 975b2c5..9a0d7c9 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -376,6 +376,7 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
}
writel(cmd-cmdarg, mmc_base-arg);
+ udelay(20); /* To fix No status update error on eMMC */
writel((cmd-cmdidx 24) | flags, mmc_base-cmd);
start = get_timer(0);
@@ -480,7 +481,7 @@ static int mmc_write_data(struct hsmmc *mmc_base, const
char *buf,
unsigned int count;
/*
-* Start Polled Read
+* Start Polled Write
*/
count = (size MMCSD_SECTOR_SIZE) ? MMCSD_SECTOR_SIZE : size;
count /= 4;
@@ -586,6 +587,8 @@ int omap_mmc_init(int dev_index, uint host_caps_mask, uint
f_max, int cd_gpio,
{
struct mmc *mmc = hsmmc_dev[dev_index];
struct omap_hsmmc_data *priv_data = hsmmc_dev_data[dev_index];
+ uint host_caps_val = MMC_MODE_4BIT | MMC_MODE_HS_52MHz | MMC_MODE_HS |
+MMC_MODE_HC;
sprintf(mmc-name, OMAP SD/MMC);
mmc-send_cmd = mmc_send_cmd;
@@ -600,11 +603,20 @@ int omap_mmc_init(int dev_index, uint host_caps_mask,
uint f_max, int cd_gpio,
#ifdef OMAP_HSMMC2_BASE
case 1:
priv_data-base_addr = (struct hsmmc *)OMAP_HSMMC2_BASE;
+#if (defined(CONFIG_OMAP44XX) || defined(CONFIG_OMAP54XX) || \
+ defined(CONFIG_DRA7XX)) defined(CONFIG_HSMMC2_8BIT)
+ /* Enable 8-bit interface for eMMC on OMAP4/5 or DRA7XX */
+ host_caps_val |= MMC_MODE_8BIT;
+#endif
break;
#endif
#ifdef OMAP_HSMMC3_BASE
case 2:
priv_data-base_addr = (struct hsmmc *)OMAP_HSMMC3_BASE;
+#if defined(CONFIG_DRA7XX) defined(CONFIG_HSMMC3_8BIT)
+ /* Enable 8-bit interface for eMMC on DRA7XX */
+ host_caps_val |= MMC_MODE_8BIT;
+#endif
break;
#endif
default:
@@ -620,8 +632,7 @@ int omap_mmc_init(int dev_index, uint host_caps_mask, uint
f_max, int cd_gpio,
mmc-getwp = omap_mmc_getwp;
mmc-voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;
- mmc-host_caps = (MMC_MODE_4BIT | MMC_MODE_HS_52MHz | MMC_MODE_HS |
- MMC_MODE_HC) ~host_caps_mask;
+ mmc-host_caps = host_caps_val ~host_caps_mask;
mmc-f_min = 40;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 6/7] USB: usb-hub: Add a weak function for resetting devices
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 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 with OMAP4460, both of which employ HSIC chips (LAN9730 and USB4640 on the OMAP5 board, and USB4640 on the OMAP4), along with a ULPI PHY (TUSB1210) on both boards. I had the pleasure of bringing up both boards with U-Boot a few months back, including USB EHCI, and can state the following: Device reset after port power is applied is needed for the OMAP5 HSIC devices only. The ULPI PHY on both boards doesn't even have a hardware reset connected, nevertheless the device attached to it gets enumerated (even without performing PHY software reset via the ULPI viewport). I performed the HSIC device reset by calling a board function from within the ehci_hcd.c driver, which is compiled only for the OMAP5, and only if we have HSIC devices. An obsolete patch for this, working on my board, can still be found at http://patchwork.ozlabs.org/patch/232742/, as well as a RFC for the 5432uevm (untested) at http://patchwork.ozlabs.org/patch/244124/ On the OMAP4 board this reset is not needed, the HSIC device gets enumerated straightforward. I don't know about other arches, but I'm not sure that having an unconditional common call, although weak, in usb_hub.c is the best solution. Best regards, Lubo I see your patches and see that you have added a omap5 specific call to reset the device in the ehci-hcd.c. I originally had a similar implementation in ehci-hcd but decided to move it up to the usb-hub. http://patchwork.ozlabs.org/patch/258229/ But I can move it back since the patch exists. This make it all board specific because as you point out it is only needed in HSIC connection Crazy question was there any support documentation for the OMAP5 HSIC issue? Well, none that I know of. Apart from the published HSIC bug (errata ID i774), which however seems unrelated to this particular issue, I'm not aware of any other documented problems. But I must admit that I'm not a TI employee anymore (my xID has expired in April) and at present don't have access to TI's internal stuff, so my info could be obsolete. You could try to contact Jerome Angeloni j-angel...@ti.com, if he still has the TI account active - he was the guy at TI France with most experience with OMAP USB applications. But, as you know, TIF is gone... Dan -- -- Dan Murphy Regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 6/7] USB: usb-hub: Add a weak function for resetting devices
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 with OMAP4460, both of which employ HSIC chips (LAN9730 and USB4640 on the OMAP5 board, and USB4640 on the OMAP4), along with a ULPI PHY (TUSB1210) on both boards. I had the pleasure of bringing up both boards with U-Boot a few months back, including USB EHCI, and can state the following: Device reset after port power is applied is needed for the OMAP5 HSIC devices only. The ULPI PHY on both boards doesn't even have a hardware reset connected, nevertheless the device attached to it gets enumerated (even without performing PHY software reset via the ULPI viewport). I performed the HSIC device reset by calling a board function from within the ehci_hcd.c driver, which is compiled only for the OMAP5, and only if we have HSIC devices. An obsolete patch for this, working on my board, can still be found at http://patchwork.ozlabs.org/patch/232742/, as well as a RFC for the 5432uevm (untested) at http://patchwork.ozlabs.org/patch/244124/ On the OMAP4 board this reset is not needed, the HSIC device gets enumerated straightforward. I don't know about other arches, but I'm not sure that having an unconditional common call, although weak, in usb_hub.c is the best solution. Best regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] v2013.07-rc2
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. Everything should be working right now, but please test. Related to this is the ability to have crytpographically signed images. It's like secure boot in UEFI land, but hopefully without the kerfuffle. 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. What about Michael's patch http://patchwork.ozlabs.org/patch/250290/ It is a bug fix actually (and happens to affect two of our boards ;) ). Thanks, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] lib/rsa/rsa-sig.c: compile on OS X
Hi Andreas, Interfaces exposed by error.h seems not to be used in rsa-sig.c, remove it. This also fixes an compile error on OS X: ---8--- u-boot/lib/rsa/rsa-sign.c:23:19: error: error.h: No such file or directory ---8--- Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com --- 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 U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] tools/proftool: add missing definition
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 http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] Makefile: fix readelf usage
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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mkimage: Build signing only if board has CONFIG_FIT_SIGNATURE
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 mailto:s...@chromium.org): Is this correct on Mac OS? I'll check it these days. Unfortunately regex is behaving differently on OS X too, so prooftool.c is not compiling: ---8--- proftool.c: In function ‘check_trace_config_line’: proftool.c:336: error: ‘REG_NOERROR’ undeclared (first use in this function) ---8--- I'll check this too. Thank you! I do actually have a Mac somewhere but just not the enthusiasm to get their baroque dev env running. Use third party stuff like fink, macports or something like that. Right. I'm using macports, with relatively fresh gcc, arm crosscomp and binutils (one has to install the Xcode Command Line Tools first however). Then I use Xcode as editor only. One known problem with MacOS X is that if the filesystem is not case-sensitive (and by default it is not on factory-formatted Mac boot drives), we may run into some make errors. And making it case-sensitive requires HDD reformatting... Or creating a separate partition... Or buying another drive for development. I had a crack at installing pygame and it nearly finished me off. Is there a web page somewhere with simple instructions? finkproject.org ;) No, not really something on u-boot or linux dev on Mac. Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] gpio: omap_gpio: Fix valid gpio range for AM33XX
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 CONFIG_OMAP_MAX_GPIO because having CONFIG_ prefix
seems meaning it can be configurable in configs.
drivers/gpio/omap_gpio.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/omap_gpio.c b/drivers/gpio/omap_gpio.c
index a30d7f0..6fa57c9 100644
--- a/drivers/gpio/omap_gpio.c
+++ b/drivers/gpio/omap_gpio.c
@@ -40,6 +40,12 @@
#include asm/io.h
#include asm/errno.h
+#if defined(CONFIG_AM33XX)
+#define OMAP_MAX_GPIO128
+#else
+#define OMAP_MAX_GPIO192
+#endif
Please be aware that OMAP54XX and DRA7XX SoCs have 8 banks per 32 GPIOs,
that is, 256 in total. The DRA7xx config defines CONFIG_DRA7XX, but also
includes omap5_common.h, where CONFIG_OMAP54XX is defined (due to sharing
of many internal IPs with the OMAP5, including GPIO). The above definitions
should be changed to something like:
#if defined(CONFIG_OMAP54XX)
#define OMAP_MAX_GPIO 256 /* OMAP54XX and DRA7XX */
#else
#if defined (CONFIG_AM33XX)
#define OMAP_MAX_GPIO 128
#else
#define OMAP_MAX_GPIO 192 /* All other OMAP3/4 */
#endif
#endif
+
#define OMAP_GPIO_DIR_OUT0
#define OMAP_GPIO_DIR_IN 1
@@ -55,7 +61,7 @@ static inline int get_gpio_index(int gpio)
int gpio_is_valid(int gpio)
{
- return (gpio = 0) (gpio 192);
+ return (gpio = 0) (gpio OMAP_MAX_GPIO);
}
static int check_gpio(int gpio)
Regards,
Lubo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] gpio: omap_gpio: Fix valid gpio range for AM33XX
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 it.
This change is mainly based on Stefan's comment, however I use
OMAP_MAX_GPIO instead of CONFIG_OMAP_MAX_GPIO because having CONFIG_ prefix
seems meaning it can be configurable in configs.
drivers/gpio/omap_gpio.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/omap_gpio.c b/drivers/gpio/omap_gpio.c
index a30d7f0..6fa57c9 100644
--- a/drivers/gpio/omap_gpio.c
+++ b/drivers/gpio/omap_gpio.c
@@ -40,6 +40,12 @@
#include asm/io.h
#include asm/errno.h
+#if defined(CONFIG_AM33XX)
+#define OMAP_MAX_GPIO128
+#else
+#define OMAP_MAX_GPIO192
+#endif
Please be aware that OMAP54XX and DRA7XX SoCs have 8 banks per 32 GPIOs,
that is, 256 in total. The DRA7xx config defines CONFIG_DRA7XX, but also
includes omap5_common.h, where CONFIG_OMAP54XX is defined (due to sharing
of many internal IPs with the OMAP5, including GPIO). The above definitions
should be changed to something like:
#if defined(CONFIG_OMAP54XX)
#define OMAP_MAX_GPIO 256 /* OMAP54XX and DRA7XX */
In arch/arm/cpu/armv7/omap5/hwinit.c
we have below settings:
static struct gpio_bank gpio_bank_54xx[6] = {
{ (void *)OMAP54XX_GPIO1_BASE, METHOD_GPIO_24XX },
{ (void *)OMAP54XX_GPIO2_BASE, METHOD_GPIO_24XX },
{ (void *)OMAP54XX_GPIO3_BASE, METHOD_GPIO_24XX },
{ (void *)OMAP54XX_GPIO4_BASE, METHOD_GPIO_24XX },
{ (void *)OMAP54XX_GPIO5_BASE, METHOD_GPIO_24XX },
{ (void *)OMAP54XX_GPIO6_BASE, METHOD_GPIO_24XX },
};
const struct gpio_bank *const omap_gpio_bank = gpio_bank_54xx;
So gpio_bank_54xx only has 6 entries rather than 8 entries.
Seems need to fix this before setting OMAP_MAX_GPIO to 256.
Sure. File arch/arm/include/asm/arch-omap5/gpio.h shall need
fixing as well, by adding:
#define OMAP54XX_GPIO7_BASE 0x48051000
#define OMAP54XX_GPIO8_BASE 0x48053000
I'm wondering if it's ok to have this patch as is, and then an incremental
patch to set gpio_bank_54xx[] and OMAP_MAX_GPIO for
OMAP54XX and DRA7XX.
Feel free to proceed as you wish. If you modify hwint.c and gpio.h, then
the three patches could be combined in a series, e.g. Fix valid GPIO
range for OMAP.
Tom?
Regards,
Axel
Thanks,
Lubo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] gpio: omap_gpio: Fix valid gpio range for AM33XX
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 are defined, and the number of GPIOs is
implicitly obvious. And we shall have no ugly #ifdefs in the GPIO driver.
Tom, what 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-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 CONFIG_OMAP_MAX_GPIO because having CONFIG_ prefix
seems meaning it can be configurable in configs.
drivers/gpio/omap_gpio.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/omap_gpio.c b/drivers/gpio/omap_gpio.c
index a30d7f0..6fa57c9 100644
--- a/drivers/gpio/omap_gpio.c
+++ b/drivers/gpio/omap_gpio.c
@@ -40,6 +40,12 @@
#include asm/io.h
#include asm/errno.h
+#if defined(CONFIG_AM33XX)
+#define OMAP_MAX_GPIO128
+#else
+#define OMAP_MAX_GPIO192
+#endif
Please be aware that OMAP54XX and DRA7XX SoCs have 8 banks per 32 GPIOs,
that is, 256 in total. The DRA7xx config defines CONFIG_DRA7XX, but also
includes omap5_common.h, where CONFIG_OMAP54XX is defined (due to sharing
of many internal IPs with the OMAP5, including GPIO). The above definitions
should be changed to something like:
#if defined(CONFIG_OMAP54XX)
#define OMAP_MAX_GPIO 256 /* OMAP54XX and DRA7XX */
In arch/arm/cpu/armv7/omap5/hwinit.c
we have below settings:
static struct gpio_bank gpio_bank_54xx[6] = {
{ (void *)OMAP54XX_GPIO1_BASE, METHOD_GPIO_24XX },
{ (void *)OMAP54XX_GPIO2_BASE, METHOD_GPIO_24XX },
{ (void *)OMAP54XX_GPIO3_BASE, METHOD_GPIO_24XX },
{ (void *)OMAP54XX_GPIO4_BASE, METHOD_GPIO_24XX },
{ (void *)OMAP54XX_GPIO5_BASE, METHOD_GPIO_24XX },
{ (void *)OMAP54XX_GPIO6_BASE, METHOD_GPIO_24XX },
};
const struct gpio_bank *const omap_gpio_bank = gpio_bank_54xx;
So gpio_bank_54xx only has 6 entries rather than 8 entries.
Seems need to fix this before setting OMAP_MAX_GPIO to 256.
Sure. File arch/arm/include/asm/arch-omap5/gpio.h shall need
fixing as well, by adding:
#define OMAP54XX_GPIO7_BASE 0x48051000
#define OMAP54XX_GPIO8_BASE 0x48053000
I'm wondering if it's ok to have this patch as is, and then an incremental
patch to set gpio_bank_54xx[] and OMAP_MAX_GPIO for
OMAP54XX and DRA7XX.
Feel free to proceed as you wish. If you modify hwint.c and gpio.h, then
the three patches could be combined in a series, e.g. Fix valid GPIO
range for OMAP.
Tom?
Regards,
Axel
Thanks,
Lubo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] gpio: omap_gpio: Fix valid gpio range for AM33XX
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 are defined, and the number of GPIOs is implicitly obvious. And we shall have no ugly #ifdefs in the GPIO driver. This sounds good. I vote for doing it this way ... Sure, but for things to work on the OMAP5 SoCs, the GPIO modules 7 8 clocks have to be enabled as well, otherwise we get a Data Abort exception. This requires one more fix in arch/arm/cpu/armv7/omap5/hw_data.c: (*prcm)-cm_l4per_gpio7_clkctrl, (*prcm)-cm_l4per_gpio8_clkctrl, have to be added to the clk_modules_hw_auto_essential[] array. I'm not mentioning here that, in order to test this in U-Boot, the pads that are intended to be used as GPIO have to be properly configured (the GPIO mux mode selected). For me the easiest way to do this was by again defining CONFIG_SYS_ENABLE_PADS_ALL (which is being descoped) because my board mux file has quite a lot of pads set to GPIO in the non_essential array. I have some additional concerns as well: on the different SoCs we have different GPIOs that are input-only or output-only, and this is currently not handled by the driver in any way. We have just to hope that users are educated enough... Unfortunately my experience tells me that very few people care to read these thousands of pages long tech docs :( . Anyway, I guess we shall have to leave this as is for now... I would suggest that Axel withdraws V3 and makes a V4 (and, please, cleanly based on master branch, not incremental), where: 1. The OMAP_MAX_GPIO defines are moved to all arch/arm/include/asm/arch-omap*/gpio.h files, and 2. The fix to arch/arm/cpu/armv7/omap5/hw_data.c is made - this affects OMAP54XX and DRA7XX. Or perhaps an entirely new patch subject (that is, new V1 patch), so that no confusion happens - we have actually shifted the scope a bit with these additional fixes. Something like ARM: OMAP: GPIO: Fix valid range and enable usage of all GPIOs on OMAP5 Otherwise, functionally tested on a custom OMAP5430 board with some GPIOs 191, works OK (with all discussed fixes applied manually). Shall give my Tested-by: when I apply the final version as a patch and test again. bye, Heiko Regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] OMAP: gpio: Introduce get_omap_gpio_count() function to get gpio count
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 SoCs.
These SoCs have various gpio count. Thus introduce get_omap_gpio_count()
function to get correct gpio count.
Signed-off-by: Axel Lin axel@ingics.com
---
arch/arm/cpu/armv7/am33xx/board.c | 5 +
arch/arm/cpu/armv7/omap3/board.c | 5 +
arch/arm/cpu/armv7/omap4/hwinit.c | 5 +
arch/arm/cpu/armv7/omap5/hwinit.c | 5 +
arch/arm/include/asm/omap_gpio.h | 1 +
drivers/gpio/omap_gpio.c | 2 +-
6 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/am33xx/board.c
b/arch/arm/cpu/armv7/am33xx/board.c
index 885fb2d..405d649 100644
--- a/arch/arm/cpu/armv7/am33xx/board.c
+++ b/arch/arm/cpu/armv7/am33xx/board.c
@@ -51,6 +51,11 @@ static const struct gpio_bank gpio_bank_am33xx[4] = {
const struct gpio_bank *const omap_gpio_bank = gpio_bank_am33xx;
+unsigned int get_omap_gpio_count(void)
+{
+ return ARRAY_SIZE(gpio_bank_am33xx) * 32;
+}
+
#if defined(CONFIG_OMAP_HSMMC) !defined(CONFIG_SPL_BUILD)
int cpu_mmc_init(bd_t *bis)
{
diff --git a/arch/arm/cpu/armv7/omap3/board.c
b/arch/arm/cpu/armv7/omap3/board.c
index b72fadc..950b13f 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -65,6 +65,11 @@ static const struct gpio_bank gpio_bank_34xx[6] = {
const struct gpio_bank *const omap_gpio_bank = gpio_bank_34xx;
+unsigned int get_omap_gpio_count(void)
+{
+ return ARRAY_SIZE(gpio_bank_34xx) * 32;
+}
+
#ifdef CONFIG_SPL_BUILD
/*
* We use static variables because global data is not ready yet.
diff --git a/arch/arm/cpu/armv7/omap4/hwinit.c
b/arch/arm/cpu/armv7/omap4/hwinit.c
index 81f5a48..3212980 100644
--- a/arch/arm/cpu/armv7/omap4/hwinit.c
+++ b/arch/arm/cpu/armv7/omap4/hwinit.c
@@ -51,6 +51,11 @@ static const struct gpio_bank gpio_bank_44xx[6] = {
const struct gpio_bank *const omap_gpio_bank = gpio_bank_44xx;
+unsigned int get_omap_gpio_count(void)
+{
+ return ARRAY_SIZE(gpio_bank_44xx) * 32;
+}
+
#ifdef CONFIG_SPL_BUILD
/*
* Some tuning of IOs for optimal power and performance
diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c
b/arch/arm/cpu/armv7/omap5/hwinit.c
index 11ba36b..58c77e7 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -56,6 +56,11 @@ static struct gpio_bank gpio_bank_54xx[8] = {
const struct gpio_bank *const omap_gpio_bank = gpio_bank_54xx;
+unsigned int get_omap_gpio_count(void)
+{
+ return ARRAY_SIZE(gpio_bank_54xx) * 32;
+}
+
#ifdef CONFIG_SPL_BUILD
/* LPDDR2 specific IO settings */
static void io_settings_lpddr2(void)
diff --git a/arch/arm/include/asm/omap_gpio.h
b/arch/arm/include/asm/omap_gpio.h
index 1ebfa86..5e25707 100644
--- a/arch/arm/include/asm/omap_gpio.h
+++ b/arch/arm/include/asm/omap_gpio.h
@@ -46,6 +46,7 @@ struct gpio_bank {
};
extern const struct gpio_bank *const omap_gpio_bank;
+extern unsigned int get_omap_gpio_count(void);
#define METHOD_GPIO_24XX 4
diff --git a/drivers/gpio/omap_gpio.c b/drivers/gpio/omap_gpio.c
index a30d7f0..1088803 100644
--- a/drivers/gpio/omap_gpio.c
+++ b/drivers/gpio/omap_gpio.c
@@ -55,7 +55,7 @@ static inline int get_gpio_index(int gpio)
int gpio_is_valid(int gpio)
{
- return (gpio = 0) (gpio 192);
+ return (gpio = 0) (gpio get_omap_gpio_count());
}
static int check_gpio(int gpio)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: OMAP: GPIO: Fix valid range and enable usage of all GPIOs on OMAP5
Hi Axel, On 21/06/13 13:54, Axel Lin wrote: The omap_gpio driver is used by AM33XX, OMAP3/4, OMAP54XX and DRA7XX SoCs. These SoCs have different gpio count but currently omap_gpio driver uses hard coded 192 which is wrong. This patch fixes this issue by: 1. Move define of OMAP_MAX_GPIO 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 1/2] gpio: omap_gpio: Fix valid gpio range for AM33XX [1] [PATCH v3 2/2] gpio: omap_gpio: Fix valid GPIO range for OMAP5 [2] [PATCH 1/2] OMAP5: Fix gpio_bank_54xx setting [3] [PATCH 2/2] OMAP: gpio: Introduce get_omap_gpio_count() function to get gpio count [4] Applied and tested on a custom OMAP5430 board with some GPIOs from banks 7 8. Works OK. 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
Re: [U-Boot] [PATCH] image: Use ENOENT instead of ENOMEDIUM for better compatibility
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 with the following tools used for building U-Boot: arm-none-eabi-gcc (GCC) 4.7.2 GNU ld (GNU Binutils) 2.23.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] v2013.07-rc1
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. I've just made a clean clone of u-boot/master and tried to build my board (after adding what's needed), and then also the omap5_uevm. In both cases the build fails with following error: gcc -g -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /Users/imac/Documents/UB2013.07/include/libfdt_env.h -idirafter /Users/imac/Documents/UB2013.07/include -idirafter /Users/imac/Documents/UB2013.07/include2 -idirafter /Users/imac/Documents/UB2013.07/include -I /Users/imac/Documents/UB2013.07/lib/libfdt -I /Users/imac/Documents/UB2013.07/tools -DCONFIG_SYS_TEXT_BASE=0x80E8 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -c -o image-fit.o /Users/imac/Documents/UB2013.07/common/image-fit.c /Users/imac/Documents/UB2013.07/common/image-fit.c: In function 'fit_image_load': /Users/imac/Documents/UB2013.07/common/image-fit.c:1560:11: error: 'ENOMEDIUM' undeclared (first use in this function) /Users/imac/Documents/UB2013.07/common/image-fit.c:1560:11: note: each undeclared identifier is reported only once for each function it appears in make[1]: *** [image-fit.o] Error 1 make: *** [tools] Error 2 Lubos-iMac:UB2013.07 imac$ All #include stuff seems OK. Any ideas? Regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] v2013.07-rc1
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. I've got a good bit of stuff I need to deal with myself still, but please prod me all the same. I've just made a clean clone of u-boot/master and tried to build my board (after adding what's needed), and then also the omap5_uevm. In both cases the build fails with following error: gcc -g -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /Users/imac/Documents/UB2013.07/include/libfdt_env.h -idirafter /Users/imac/Documents/UB2013.07/include -idirafter /Users/imac/Documents/UB2013.07/include2 -idirafter /Users/imac/Documents/UB2013.07/include -I /Users/imac/Documents/UB2013.07/lib/libfdt -I /Users/imac/Documents/UB2013.07/tools -DCONFIG_SYS_TEXT_BASE=0x80E8 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -c -o image-fit.o /Users/imac/Documents/UB2013.07/common/image-fit.c /Users/imac/Documents/UB2013.07/common/image-fit.c: In function 'fit_image_load': /Users/imac/Documents/UB2013.07/common/image-fit.c:1560:11: error: 'ENOMEDIUM' undeclared (first use in this function) /Users/imac/Documents/UB2013.07/common/image-fit.c:1560:11: note: each undeclared identifier is reported only once for each function it appears in make[1]: *** [image-fit.o] Error 1 make: *** [tools] Error 2 Lubos-iMac:UB2013.07 imac$ All #include stuff seems OK. Any ideas? That might be a MacOS thing - I haven't quite had the patience to get a dev environment going on a Mac yet. Please can you try this patch and see if it helps? http://patchwork.ozlabs.org/patch/251685/ Many thanks for the hint - I didn't realize immediately that this is host stuff. U-boot now builds normally (and runs on my board :)). BTW, until this release I've been using a Mac at home to build and run U-Boot without any major issues (actually only make distclean fails, which is not crucial). Thanks, Lubo Regards, Simon Regards, Lubo ___ 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] [ANN] v2013.07-rc1
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 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. I've just made a clean clone of u-boot/master and tried to build my board (after adding what's needed), and then also the omap5_uevm. In both cases the build fails with following error: gcc -g -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /Users/imac/Documents/UB2013.07/include/libfdt_env.h -idirafter /Users/imac/Documents/UB2013.07/include -idirafter /Users/imac/Documents/UB2013.07/include2 -idirafter /Users/imac/Documents/UB2013.07/include -I /Users/imac/Documents/UB2013.07/lib/libfdt -I /Users/imac/Documents/UB2013.07/tools -DCONFIG_SYS_TEXT_BASE=0x80E8 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -c -o image-fit.o /Users/imac/Documents/UB2013.07/common/image-fit.c /Users/imac/Documents/UB2013.07/common/image-fit.c: In function 'fit_image_load': /Users/imac/Documents/UB2013.07/common/image-fit.c:1560:11: error: 'ENOMEDIUM' undeclared (first use in this function) /Users/imac/Documents/UB2013.07/common/image-fit.c:1560:11: note: each undeclared identifier is reported only once for each function it appears in make[1]: *** [image-fit.o] Error 1 make: *** [tools] Error 2 Lubos-iMac:UB2013.07 imac$ All #include stuff seems OK. Any ideas? That might be a MacOS thing - I haven't quite had the patience to get a dev environment going on a Mac yet. Please can you try this patch and see if it helps? http://patchwork.ozlabs.org/patch/251685/ Many thanks for the hint - I didn't realize immediately that this is host stuff. U-boot now builds normally (and runs on my board :)). BTW, until this release I've been using a Mac at home to build and run U-Boot without any major issues (actually only make distclean fails, which is not crucial). We have done a few fixes with 'make distclean' before - is this MacOS-specific, or s general bug? Well, I'm not a UNIX expert (nor Linux; in fact I'm more in hardware). I get this: Lubos-iMac:UB2013.07 imac$ make CROSS_COMPILE= arm-none-eabi- distclean rm: SPL: is a directory make: *** [clobber] Error 1 Lubos-iMac:UB2013.07 imac$ For OMAP we don't have a 'SPL' file; there is the 'spl' directory however, and although MacOS is case-sensitive, this somehow produces the error in '@rm -f $(obj)SPL' (clobber: of main Makefile). Regards, Simon Best regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/6] Optimize ARM relocation
Hi Albert, On 11/06/13 15:47, Albert ARIBAUD wrote: Hi Albert, On Tue, 11 Jun 2013 14:17:29 +0200, Albert ARIBAUD albert.u.b...@aribaud.net wrote: This series optimizes relocation by ensuring ARM binaries only use one type of relocation record, R_ARM_RELATIVE., then optimizing relocation code accordingly. This is a cosmetic version only; if no one complains loudly, this will be the final version too. So people, as this touches ARM relocation, I would appreciate it if a few people could test it on their own ARM HW target and see if they still get a prompt, if command 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
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 00264001 | | | +-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 lpo...@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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
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 00264001 | | | +-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 lpo...@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 mich...@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
Re: [U-Boot] [PATCH] usb: omap: ulpi: fix ulpi reading/writing functions
Hi Michael,
A minor suggestion to clarify the explanation (its HW that requires +1):
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.
-^
The OMAP INSNREG05_ULPI register expects a value of 1 for Port 1 and of 2 for
Port 2 in the PORTSEL field.
Add a +1 fix the problem
Signed-off-by: Michael Trimarchi mich...@amarulasolutions.com
---
drivers/usb/ulpi/omap-ulpi-viewport.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/ulpi/omap-ulpi-viewport.c
b/drivers/usb/ulpi/omap-ulpi-viewport.c
index 2a42033..4db7fa4 100644
--- a/drivers/usb/ulpi/omap-ulpi-viewport.c
+++ b/drivers/usb/ulpi/omap-ulpi-viewport.c
@@ -61,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 = (OMAP_ULPI_START | (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);
@@ -70,7 +70,7 @@ 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) |
+ 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);
As for the patch itself, tested on a custom OMAP5430 board 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
Re: [U-Boot] [PATCH] usb: omap: ulpi: fix ulpi reading/writing functions
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 the problem Signed-off-by: Michael Trimarchi mich...@amarulasolutions.com --- drivers/usb/ulpi/omap-ulpi-viewport.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/ulpi/omap-ulpi-viewport.c b/drivers/usb/ulpi/omap-ulpi-viewport.c index 2a42033..4db7fa4 100644 --- a/drivers/usb/ulpi/omap-ulpi-viewport.c +++ b/drivers/usb/ulpi/omap-ulpi-viewport.c @@ -61,7 +61,7 @@ static int ulpi_request(struct ulpi_viewport *ulpi_vp, u32 value) I now see that you have not rebased on a clean u-boot-ti/master. This patch is incremental to your older version, but without any notification about this, and without version info in the subject. I guess you shall have to repost. Best regards, Lubomir ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
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 00264001 | | | +-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
Re: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1
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 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...@ti.com --- arch/arm/include/asm/arch-omap5/omap.h |3 ++- drivers/mmc/omap_hsmmc.c | 26 ++ drivers/power/palmas.c | 25 - include/configs/omap5_common.h |4 include/configs/omap5_uevm.h |5 - include/palmas.h |6 +- 6 files changed, 49 insertions(+), 20 deletions(-) [snip] + /* set LDO9 TWL6035 to 3V */ LDO9? TWL6035? If this function is used on the DRA7xx boards only (with TPS659038), you should add some comment above. Ok ll add the comment. + val = 0x2b; /* (3 - 0.9) * 20 + 1 */ Why not use definitions for the voltage? You could take them from http://patchwork.ozlabs.org/patch/244103/ where some values are defined. Yes, Ill rebase this patch on top of your patch and use those defines. Please be aware that my above mentioned patch has not been reviewed/ tested/acked/nacked/whatever by nobody (except possibly a quick look by Nishanth Menon, who had some objections). I wrote it when bringing up a custom OMAP5 board, and most probably it shall not go into mainline in its current form, if ever. I gave it only as an example of how things could be done cleaner. Feel free to use the code as you wish, but I'm afraid that applying it as a patch to your tree and basing upon it might run you into problems when you later sync with mainline. Tom, your opinion? OK, so at the time it was nothing will really use this code except test functions. Looks like we have a use for mmc1_ldo9 code at least, so lets rework the first patch for adding that + cleanups wrt constants. Well, I'm not quite sure that this LDO9 function would be the only one used (or LDO1 on the DRA7xx board). Judging from omapboot for the OMAP5 boards for example, SMPS7 (it delivers the common 1.8 V I/O supply) is set to 'Forced PWM' mode in order to reduce board noise - there sure has been a reason to do so and sacrifice converter efficiency. Therefore I added similar functionality in my patch to the Palmas driver (and am explicitly calling it in my board init). The option to bypass LDO9 on OMAP5+TWL603x boards seems quite mandatory as well, if hardware is designed such that the SD card socket has a separate fixed 3.3 V supply which also powers the LDO9 input (the uEVM for example). On the DRA7xx+TPS659038 board the power scheme is different and this does not apply. OK, lets see. That so lets keep your patch as-is, since we've now got -ffunction-sections/-fdata-sections/--gc-sections on ARM for main U-Boot, these small things won't hurt like they used to. OK, but then I would like to do some cleanup first - remove the audio power stuff (shall have it in my board file), as well as either sort out the function naming: - Those functions that are specific to a SoC+PMIC combination are named e.g. twl603x_... or tps659038_... so that they explicitly indicate the hardware that they are working with (actually almost all functions are such). This is however sort of regression, and requires fixes in the files calling these functions; or, alternatively: - Introduce generic functions with fixed names, palmas_bla_bla(), sort of wrappers, which in their bodies perform the appropriate action based on the #ifdefs defining the platform hardware (where we could also define the particular LDO which for example a palmas_mmc1_poweron_ldo() generic function would manipulate). Drawback: again #ifdefs. Advantage: single place where this stuff is located, and where other PMIC/LDO combinations can be added without affecting other code. And this generic palmas_mmc1_poweron_ldo() function would be called by another generic function, e.g. omap_sdmmc_poweron(), located in the board file, only if needed by the particular hardware. omap_sdmmc_poweron(), on its hand, is the function that is to be called from within the pbias routines in omap_hsmmc.c, and not the hardware- dependant functions directly. So we get the abstraction. What do you think? Lokesh, your opinion? Regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] OMAP5: Fix bug in omap5_es1_prcm struct
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
devices this uninitialized value causes a second (warm) 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 a/arch/arm/cpu/armv7/omap5/prcm-regs.c
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index e9f6a32..f29ac77 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -298,6 +298,7 @@ struct prcm_regs const omap5_es1_prcm = {
.cm_wkupaon_io_srcomp_clkctrl = 0x4ae07898,
.prm_rstctrl = 0x4ae07b00,
.prm_rstst = 0x4ae07b04,
+ .prm_rsttime = 0x4ae07b08,
.prm_vc_val_bypass = 0x4ae07ba0,
.prm_vc_cfg_i2c_mode = 0x4ae07bb4,
.prm_vc_cfg_i2c_clk = 0x4ae07bb8,
Could you please apply http://patchwork.ozlabs.org/patch/246454/
to the ti tree? This is the only obstacle for my board to boot
normally with a clean u-boot-ti in respect to the OMAP5 common
stuff.
Thanks,
Lubo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1
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 we've now got -ffunction-sections/-fdata-sections/--gc-sections on ARM for main U-Boot, these small things won't hurt like they used to. OK, but then I would like to do some cleanup first - remove the audio power stuff (shall have it in my board file), as well as either sort out the function naming: - Those functions that are specific to a SoC+PMIC combination are named e.g. twl603x_... or tps659038_... so that they explicitly indicate the hardware that they are working with (actually almost all functions are such). This is however sort of regression, and requires fixes in the files calling these functions; or, alternatively: - Introduce generic functions with fixed names, palmas_bla_bla(), sort of wrappers, which in their bodies perform the appropriate action based on the #ifdefs defining the platform hardware (where we could also define the particular LDO which for example a palmas_mmc1_poweron_ldo() generic function would manipulate). Drawback: again #ifdefs. Advantage: single place where this stuff is located, and where other PMIC/LDO combinations can be added without affecting other code. I think, we can have function pointers for and can populate data in the beginning or from board file based on Soc, similarly what we did for prcm structure. Regards, Lokesh OK, sounds reasonable. I think this should be done in a future release however, after careful investigation and planning. At present, I guess, we are staying with the current situation. Today I shall submit an updated version of my patch to the palmas driver - sort of compromise between clean code and ease of use. I have included your stuff there, so should work out of the box on the dra7xx_evm. Please note that now we have a semi-generic function to power on the appropriate SDMMC LDO: the old palmas_mmc1_poweron_ldo(), which you shall have to call in omap_hsmmc. Differentiation of which particular LDO to control within which PMIC is done in driver, based on the board #ifdefs. If Tom approves this patch and applies it, we shall all be happy with working boards, although the code may not be perfect. I would also like to ask you to send me a Register Manual of the TPS659038/9, if possible. If you have any NDA concerns, then just check if the LDO1 control register has a BYPASS option and tell me. Thanks. Best regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3] ARM: OMAP5: Power: Add more functionality to Palmas driver
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 for the SD/MMC interface).
V2 aligns to changed PMIC name (and file names accordingly)
from twl6035 to Palmas and is based on current u-boot-ti
master.
drivers/power/palmas.c | 130 +++-
include/palmas.h | 90 ++---
2 files changed, 201 insertions(+), 19 deletions(-)
diff --git a/drivers/power/palmas.c b/drivers/power/palmas.c
index 09c832d..6c60b5f 100644
--- a/drivers/power/palmas.c
+++ b/drivers/power/palmas.c
@@ -25,28 +25,134 @@
void palmas_init_settings(void)
{
- return;
+#ifdef CONFIG_PALMAS_SMPS7_FPWM
+ int err;
+ /*
+* Set SMPS7 (1.8 V I/O supply on platforms with TWL6035/37) to
+* forced PWM mode. This reduces noise (but affects efficiency).
+*/
+ u8 val = SMPS_MODE_SLP_FPWM | SMPS_MODE_ACT_FPWM;
+ if ((err = palmas_i2c_write_u8(TWL603X_CHIP_P1, SMPS7_CTRL, val)))
+ printf(palmas: could not force PWM for SMPS7: err = %d\n,
+ err);
+#endif
}
int palmas_mmc1_poweron_ldo(void)
{
u8 val = 0;
- /* set LDO9 TWL6035 to 3V */
- val = 0x2b; /* (3 -.9)*28 +1 */
-
- if (palmas_i2c_write_u8(0x48, LDO9_VOLTAGE, val)) {
- printf(twl6035: could not set LDO9 voltage.\n);
+#if defined(CONFIG_DRA7XX)
+ /*
+* Currently valid for the dra7xx_evm board:
+* Set TPS659038 LDO1 to 3.0 V
+*/
+ val = LDO_VOLT_3V0;
+ if (palmas_i2c_write_u8(TPS65903X_CHIP_P1, LDO1_VOLTAGE, val)) {
+ printf(tps65903x: could not set LDO1 voltage.\n);
+ return 1;
+ }
+ /* TURN ON LDO1 */
+ val = RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+ if (palmas_i2c_write_u8(TPS65903X_CHIP_P1, LDO1_CTRL, val)) {
+ printf(tps65903x: could not turn on LDO1.\n);
return 1;
}
+ return 0;
+#else
+ /*
+* We assume that this is a OMAP543X + TWL603X board:
+* Set TWL6035/37 LDO9 to 3.0 V
+*/
+ val = LDO_VOLT_3V0;
+ return twl603x_mmc1_set_ldo9(val);
+#endif
+}
- /* TURN ON LDO9 */
- val = LDO_ON | LDO_MODE_SLEEP | LDO_MODE_ACTIVE;
+/*
+ * On some OMAP5 + TWL603X hardware the SD card socket and LDO9_IN are
+ * powered by an external 3.3 V regulator, while the output of LDO9
+ * supplies VDDS_SDCARD for the OMAP5 interface only. This implies that
+ * LDO9 could be set to 'bypass' mode when required (e.g. for 3.3 V cards).
+ */
+int twl603x_mmc1_set_ldo9(u8 vsel)
+{
+ u8 cval=0, vval=0; /* Off by default */
+ int err;
- if (palmas_i2c_write_u8(0x48, LDO9_CTRL, val)) {
- printf(twl6035: could not turn on LDO9.\n);
- return 1;
+ if (vsel) {
+ /* Turn on */
+ if (vsel LDO_VOLT_3V3) {
+ /* Put LDO9 in bypass */
+ cval = LDO9_BYP_EN | RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+ vval = LDO_VOLT_3V3;
+ }
+ else {
+ cval = RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+ vval = vsel 0x3f;
+ }
+ }
+ if ((err = palmas_i2c_write_u8(TWL603X_CHIP_P1, LDO9_VOLTAGE, vval))) {
+ printf(twl603x: could not set LDO9 %s: err = %d\n,
+ vsel LDO_VOLT_3V3 ? bypass : voltage, err);
+ return err;
}
+ if ((err = palmas_i2c_write_u8(TWL603X_CHIP_P1, LDO9_CTRL, cval)))
+ printf(twl603x: could not turn %s LDO9: err = %d\n,
+ cval ? on : off, err);
+ return err;
+}
- return 0;
+#ifdef CONFIG_PALMAS_AUDPWR
+/*
+ * Turn audio codec power and 32 kHz clock on/off. Use for
+ * testing OMAP543X + TWL603X + TWL604X boards only.
+ */
+int twl603x_audio_power(u8 on)
+{
+ u8 cval=0, vval=0, c32k=0;
+ int err;
+
+ if (on) {
+ vval = SMPS_VOLT_2V1;
+ cval = SMPS_MODE_SLP_AUTO | SMPS_MODE_ACT_AUTO;
+ c32k = RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+ }
+ /* Set SMPS9 to 2.1 V (for TWL604x), or to 0 (off) */
+ if ((err = palmas_i2c_write_u8(TWL603X_CHIP_P1, SMPS9_VOLTAGE,
+ vval))) {
+ printf(twl603x: could not set SMPS9 voltage: err = %d\n,
+ err);
+ return err;
+ }
+ /* Turn on or off SMPS9 */
+ if ((err = palmas_i2c_write_u8(TWL603X_CHIP_P1, SMPS9_CTRL, cval))) {
+ printf(twl603x: could not turn SMPS9 %s: err = %d\n,
+ cval ? on : off, err
Re: [U-Boot] [PATCH V2 00/12] ARM: DRA7xx: Update support for DRA7xx Soc's
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 cleanup series: http://u-boot.10912.n7.nabble.com/PATCH-V2-0-4-ARM-OMAP2-Misc-Cleanup-tt155949.html Do you have any further comments on this series ? Sorry, everything looks good, and I think Lubomir's patch for MMC stuff (which means we drop 9/12 here, right?) should settle everything else out. Please be aware that my patch (latest in http://patchwork.ozlabs.org/patch/249405/) fixes the two palmas.* files only, while Lokesh's patch 9/12 affected 6 files in total (including these two). Lokesh, unfortunately you shall have to repost 9/12 after rebasing over my stuff, if it is applied. Regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4] ARM: OMAP5: Power: Add more functionality to Palmas driver
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 and adds support for the dra7xx_evm
board (power on LDO1 used for the SD/MMC interface).
V2 aligns to changed PMIC name (and file names accordingly)
from twl6035 to Palmas and is based on current u-boot-ti
master.
drivers/power/palmas.c | 134 +++-
include/palmas.h | 90 +---
2 files changed, 205 insertions(+), 19 deletions(-)
diff --git a/drivers/power/palmas.c b/drivers/power/palmas.c
index 09c832d..07b9815 100644
--- a/drivers/power/palmas.c
+++ b/drivers/power/palmas.c
@@ -25,28 +25,138 @@
void palmas_init_settings(void)
{
- return;
+#ifdef CONFIG_PALMAS_SMPS7_FPWM
+ int err;
+ /*
+* Set SMPS7 (1.8 V I/O supply on platforms with TWL6035/37) to
+* forced PWM mode. This reduces noise (but affects efficiency).
+*/
+ u8 val = SMPS_MODE_SLP_FPWM | SMPS_MODE_ACT_FPWM;
+ err = palmas_i2c_write_u8(TWL603X_CHIP_P1, SMPS7_CTRL, val);
+ if (err)
+ printf(palmas: could not force PWM for SMPS7: err = %d\n,
+ err);
+#endif
}
int palmas_mmc1_poweron_ldo(void)
{
u8 val = 0;
- /* set LDO9 TWL6035 to 3V */
- val = 0x2b; /* (3 -.9)*28 +1 */
-
- if (palmas_i2c_write_u8(0x48, LDO9_VOLTAGE, val)) {
- printf(twl6035: could not set LDO9 voltage.\n);
+#if defined(CONFIG_DRA7XX)
+ /*
+* Currently valid for the dra7xx_evm board:
+* Set TPS659038 LDO1 to 3.0 V
+*/
+ val = LDO_VOLT_3V0;
+ if (palmas_i2c_write_u8(TPS65903X_CHIP_P1, LDO1_VOLTAGE, val)) {
+ printf(tps65903x: could not set LDO1 voltage.\n);
+ return 1;
+ }
+ /* TURN ON LDO1 */
+ val = RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+ if (palmas_i2c_write_u8(TPS65903X_CHIP_P1, LDO1_CTRL, val)) {
+ printf(tps65903x: could not turn on LDO1.\n);
return 1;
}
+ return 0;
+#else
+ /*
+* We assume that this is a OMAP543X + TWL603X board:
+* Set TWL6035/37 LDO9 to 3.0 V
+*/
+ val = LDO_VOLT_3V0;
+ return twl603x_mmc1_set_ldo9(val);
+#endif
+}
- /* TURN ON LDO9 */
- val = LDO_ON | LDO_MODE_SLEEP | LDO_MODE_ACTIVE;
+/*
+ * On some OMAP5 + TWL603X hardware the SD card socket and LDO9_IN are
+ * powered by an external 3.3 V regulator, while the output of LDO9
+ * supplies VDDS_SDCARD for the OMAP5 interface only. This implies that
+ * LDO9 could be set to 'bypass' mode when required (e.g. for 3.3 V cards).
+ */
+int twl603x_mmc1_set_ldo9(u8 vsel)
+{
+ u8 cval = 0, vval = 0; /* Off by default */
+ int err;
- if (palmas_i2c_write_u8(0x48, LDO9_CTRL, val)) {
- printf(twl6035: could not turn on LDO9.\n);
- return 1;
+ if (vsel) {
+ /* Turn on */
+ if (vsel LDO_VOLT_3V3) {
+ /* Put LDO9 in bypass */
+ cval = LDO9_BYP_EN | RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+ vval = LDO_VOLT_3V3;
+ } else {
+ cval = RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+ vval = vsel 0x3f;
+ }
+ }
+ err = palmas_i2c_write_u8(TWL603X_CHIP_P1, LDO9_VOLTAGE, vval);
+ if (err) {
+ printf(twl603x: could not set LDO9 %s: err = %d\n,
+ vsel LDO_VOLT_3V3 ? bypass : voltage, err);
+ return err;
}
+ err = palmas_i2c_write_u8(TWL603X_CHIP_P1, LDO9_CTRL, cval);
+ if (err)
+ printf(twl603x: could not turn %s LDO9: err = %d\n,
+ cval ? on : off, err);
+ return err;
+}
- return 0;
+#ifdef CONFIG_PALMAS_AUDPWR
+/*
+ * Turn audio codec power and 32 kHz clock on/off. Use for
+ * testing OMAP543X + TWL603X + TWL604X boards only.
+ */
+int twl603x_audio_power(u8 on)
+{
+ u8 cval = 0, vval = 0, c32k = 0;
+ int err;
+
+ if (on) {
+ vval = SMPS_VOLT_2V1;
+ cval = SMPS_MODE_SLP_AUTO | SMPS_MODE_ACT_AUTO;
+ c32k = RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+ }
+ /* Set SMPS9 to 2.1 V (for TWL604x), or to 0 (off) */
+ err = palmas_i2c_write_u8(TWL603X_CHIP_P1, SMPS9_VOLTAGE, vval);
+ if (err) {
+ printf(twl603x: could not set SMPS9 voltage: err = %d\n,
+ err);
+ return err;
+ }
+ /* Turn on or off SMPS9 */
+ err = palmas_i2c_write_u8(TWL603X_CHIP_P1, SMPS9_CTRL, cval);
+ if (err) {
+ printf(twl603x: could not turn SMPS9 %s: err = %d\n
Re: [U-Boot] [PATCH v4] arm: dra7xx: Update the EXTRA_ENV_SETTINGS
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 - http://patchwork.ozlabs.org/patch/249084/ v3 - Updated based on comments - http://patchwork.ozlabs.org/patch/248687/ v2 - Updated with side bar maintainer comments. include/configs/dra7xx_evm.h |2 ++ include/configs/omap5_common.h |6 -- include/configs/omap5_uevm.h |1 + 3 files changed, 7 insertions(+), 2 deletions(-) [snip] #define CONFIG_SYS_PROMPTOMAP5430 EVM # Minor notice/question: why not take the opportunity and change the uEVM prompt to 'OMAP5432 EVM #'? It's not a 5430 actually... For the dra7xx board, for example, you are giving the particular DRA752 type. Best regards Lubomir ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1
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 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 ++- drivers/mmc/omap_hsmmc.c | 26 ++ drivers/power/palmas.c | 25 - include/configs/omap5_common.h |4 include/configs/omap5_uevm.h |5 - include/palmas.h |6 +- 6 files changed, 49 insertions(+), 20 deletions(-) [snip] + /* set LDO9 TWL6035 to 3V */ LDO9? TWL6035? If this function is used on the DRA7xx boards only (with TPS659038), you should add some comment above. Ok ll add the comment. + val = 0x2b; /* (3 - 0.9) * 20 + 1 */ Why not use definitions for the voltage? You could take them from http://patchwork.ozlabs.org/patch/244103/ where some values are defined. Yes, Ill rebase this patch on top of your patch and use those defines. Please be aware that my above mentioned patch has not been reviewed/ tested/acked/nacked/whatever by nobody (except possibly a quick look by Nishanth Menon, who had some objections). I wrote it when bringing up a custom OMAP5 board, and most probably it shall not go into mainline in its current form, if ever. I gave it only as an example of how things could be done cleaner. Feel free to use the code as you wish, but I'm afraid that applying it as a patch to your tree and basing upon it might run you into problems when you later sync with mainline. Tom, your opinion? OK, so at the time it was nothing will really use this code except test functions. Looks like we have a use for mmc1_ldo9 code at least, so lets rework the first patch for adding that + cleanups wrt constants. Well, I'm not quite sure that this LDO9 function would be the only one used (or LDO1 on the DRA7xx board). Judging from omapboot for the OMAP5 boards for example, SMPS7 (it delivers the common 1.8 V I/O supply) is set to 'Forced PWM' mode in order to reduce board noise - there sure has been a reason to do so and sacrifice converter efficiency. Therefore I added similar functionality in my patch to the Palmas driver (and am explicitly calling it in my board init). The option to bypass LDO9 on OMAP5+TWL603x boards seems quite mandatory as well, if hardware is designed such that the SD card socket has a separate fixed 3.3 V supply which also powers the LDO9 input (the uEVM for example). On the DRA7xx+TPS659038 board the power scheme is different and this does not apply. Best regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1
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, 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...@ti.com --- arch/arm/include/asm/arch-omap5/omap.h |3 ++- drivers/mmc/omap_hsmmc.c | 26 ++ drivers/power/palmas.c | 25 - include/configs/omap5_common.h |4 include/configs/omap5_uevm.h |5 - include/palmas.h |6 +- 6 files changed, 49 insertions(+), 20 deletions(-) [snip] + /* set LDO9 TWL6035 to 3V */ LDO9? TWL6035? If this function is used on the DRA7xx boards only (with TPS659038), you should add some comment above. Ok ll add the comment. + val = 0x2b; /* (3 - 0.9) * 20 + 1 */ Why not use definitions for the voltage? You could take them from http://patchwork.ozlabs.org/patch/244103/ where some values are defined. Yes, Ill rebase this patch on top of your patch and use those defines. Please be aware that my above mentioned patch has not been reviewed/ tested/acked/nacked/whatever by nobody (except possibly a quick look by Nishanth Menon, who had some objections). I wrote it when bringing up a custom OMAP5 board, and most probably it shall not go into mainline in its current form, if ever. I gave it only as an example of how things could be done cleaner. Feel free to use the code as you wish, but I'm afraid that applying it as a patch to your tree and basing upon it might run you into problems when you later sync with mainline. Tom, your opinion? OK, so at the time it was nothing will really use this code except test functions. Looks like we have a use for mmc1_ldo9 code at least, so lets rework the first patch for adding that + cleanups wrt constants. Well, I'm not quite sure that this LDO9 function would be the only one used (or LDO1 on the DRA7xx board). Judging from omapboot for the OMAP5 boards for example, SMPS7 (it delivers the common 1.8 V I/O supply) is set to 'Forced PWM' mode in order to reduce board noise - there sure has been a reason to do so and sacrifice converter efficiency. Therefore I added similar functionality in my patch to the Palmas driver (and am explicitly calling it in my board init). The option to bypass LDO9 on OMAP5+TWL603x boards seems quite mandatory as well, if hardware is designed such that the SD card socket has a separate fixed 3.3 V supply which also powers the LDO9 input (the uEVM for example). On the DRA7xx+TPS659038 board the power scheme is different and this does not apply. I hate this code for many reasons - a) hsmmc is used on many OMAP and DM platforms to my knowledge. b) what is being done here is to power on the LDO supplying MMC. Sorry, but I can't get if hsmmc is discussed here, or power. For OMAP5+TWL603x the LDO powering MMC (actually the removable card interface only; eMMC is another story) is turned on automatically at power-on by the PMIC sequencer, with a default voltage and mode -- otherwise we would not be able to boot from a card (ROM code does not touch the PMIC at all). We are talking here about the possibility to have additional control over this LDO, which should be board-specific, I agree. On the OMAP5 boards, for example, the call to palmas_mmc1_poweron_ldo() from within omap_hsmmc actually does not turn on LDO9 - it is on at this moment anyway. The call just makes it switch from the default bypass mode (with Vout = Vin = 3.3 V) to regulation mode and Vout = 3.0 V. Why is this done is yet another question; to me it seems useless (and possibly wrong) when the card is powered with a fixed voltage of 3.3 V. Therefore it seems reasonable to count on the PMIC defaults and remove this call from omap_hsmmc altogether, thus disengaging the PMIC driver from hsmmc, at least for OMAP5. For OMAP4 things are somewhat different. Here the TWL6030 PMIC powers both the OMAP interface and the card socket, and in addition can automatically power off the MMC LDO upon detecting card removal. ROM code *does* access the MMC LDO to turn it on and set it to 3.0 V (it starts by default at 1.8 V), but only if booting from a card. So here the call to PMIC driver should stay. Other OMAPs and derivatives - other scenarios. Anyway, omap_hsmmc.c is built for TI platforms only. If you mean the #ifdefs here, yes, things could be cleaned up by moving the SoC- specific pbias stuff to the corresponding board files (with the expense of redundancy), but this is quite an amount of work... I'm not volunteering... ;) Moreover
Re: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1
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 +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 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 ++- drivers/mmc/omap_hsmmc.c | 26 ++ drivers/power/palmas.c | 25 - include/configs/omap5_common.h |4 include/configs/omap5_uevm.h |5 - include/palmas.h |6 +- 6 files changed, 49 insertions(+), 20 deletions(-) [snip] + /* set LDO9 TWL6035 to 3V */ LDO9? TWL6035? If this function is used on the DRA7xx boards only (with TPS659038), you should add some comment above. Ok ll add the comment. + val = 0x2b; /* (3 - 0.9) * 20 + 1 */ Why not use definitions for the voltage? You could take them from http://patchwork.ozlabs.org/patch/244103/ where some values are defined. Yes, Ill rebase this patch on top of your patch and use those defines. Please be aware that my above mentioned patch has not been reviewed/ tested/acked/nacked/whatever by nobody (except possibly a quick look by Nishanth Menon, who had some objections). I wrote it when bringing up a custom OMAP5 board, and most probably it shall not go into mainline in its current form, if ever. I gave it only as an example of how things could be done cleaner. Feel free to use the code as you wish, but I'm afraid that applying it as a patch to your tree and basing upon it might run you into problems when you later sync with mainline. Tom, your opinion? OK, so at the time it was nothing will really use this code except test functions. Looks like we have a use for mmc1_ldo9 code at least, so lets rework the first patch for adding that + cleanups wrt constants. Well, I'm not quite sure that this LDO9 function would be the only one used (or LDO1 on the DRA7xx board). Judging from omapboot for the OMAP5 boards for example, SMPS7 (it delivers the common 1.8 V I/O supply) is set to 'Forced PWM' mode in order to reduce board noise - there sure has been a reason to do so and sacrifice converter efficiency. Therefore I added similar functionality in my patch to the Palmas driver (and am explicitly calling it in my board init). The option to bypass LDO9 on OMAP5+TWL603x boards seems quite mandatory as well, if hardware is designed such that the SD card socket has a separate fixed 3.3 V supply which also powers the LDO9 input (the uEVM for example). On the DRA7xx+TPS659038 board the power scheme is different and this does not apply. I hate this code for many reasons - a) hsmmc is used on many OMAP and DM platforms to my knowledge. b) what is being done here is to power on the LDO supplying MMC. Sorry, but I can't get if hsmmc is discussed here, or power. For OMAP5+TWL603x the LDO powering MMC (actually the removable card interface only; eMMC is another story) is turned on automatically at power-on by the PMIC sequencer, with a default voltage and mode -- otherwise we would not be able to boot from a card (ROM code does not touch the PMIC at all). We are talking here about the possibility to have additional control over this LDO, which should be board-specific, I agree. On the OMAP5 boards, for example, the call to palmas_mmc1_poweron_ldo() from within omap_hsmmc actually does not turn on LDO9 - it is on at this moment anyway. The call just makes it switch from the default bypass mode (with Vout = Vin = 3.3 V) to regulation mode and Vout = 3.0 V. Why is this done is yet another question; to me it seems useless (and possibly wrong) when the card is powered with a fixed voltage of 3.3 V. Therefore it seems reasonable to count on the PMIC defaults and remove this call from omap_hsmmc altogether, thus disengaging the PMIC driver from hsmmc, at least for OMAP5. For OMAP4 things are somewhat different. Here the TWL6030 PMIC powers both the OMAP interface and the card socket, and in addition can automatically power off the MMC LDO upon detecting card removal. ROM code *does* access the MMC LDO to turn it on and set it to 3.0 V (it starts by default at 1.8 V), but only if booting from a card. So here the call to PMIC driver should stay. Other OMAPs and derivatives - other scenarios. Anyway, omap_hsmmc.c is built for TI platforms only. If you mean the #ifdefs here, yes, things could be cleaned up by moving the SoC- specific pbias stuff to the corresponding board files
Re: [U-Boot] [PATCH V5] ARM: OMAP: I2C: New read, write and probe functions
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 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 require driver modification. [...] drivers/i2c/omap24xx_i2c.c | 490 +++-- 1 file changed, 299 insertions(+), 191 deletions(-) Tested on 3 arm335x based boards, which one uses i2c in SPL code for getting ram parameters, so: Tested-by: Heiko Schocher h...@denx.de Many thanks for testing, to Tom as well (he did it on the Beagleboards, but for one of the older versions, V3 I believe, right?). When it comes to versions, I see that V1 and V2 are still listed in patchwork, probably because of slightly different wording of the subject: http://patchwork.ozlabs.org/patch/233823/ http://patchwork.ozlabs.org/patch/246204/ Could you or Tom clean this up, please? Thanks. Cleared the v3 v4 version, but missed the v2 and v1, Done. just doing a MAKEALL arm with your patch applied and get this error: Configuring for omap2420h4 board... omap24xx_i2c.c:497:17: error: 'struct i2c' has no member named 'irqstatus_raw' omap24xx_i2c.c:528:12: error: 'struct i2c' has no member named 'irqstatus_raw' arm-linux-gnueabi-size: './u-boot': No such file omap24xx_i2c.c: In function 'wait_for_bb': omap24xx_i2c.c:497:17: error: 'struct i2c' has no member named 'irqstatus_raw' omap24xx_i2c.c: In function 'wait_for_event': omap24xx_i2c.c:528:12: error: 'struct i2c' has no member named 'irqstatus_raw' make[1]: *** [omap24xx_i2c.o] Fehler 1 make: *** [drivers/i2c/libi2c.o] Fehler 2 make: *** Warte auf noch nicht beendete Prozesse... Please fix this and run a MAKEALL arm before repost, thanks! We have agreed upon this breakage with Tom - the OMAP2420 shall not be supported anymore in the next release. At least I understood it that way (and have noted it accordingly in the comments). I could of course make a very simple modification that would allow build without errors, but the driver shall not work on the 2420; in order to make it work, a more serious rework is required. I don't have however any 2420 hardware to test upon. Tom? bye, Heiko Regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1
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...@ti.com
---
arch/arm/include/asm/arch-omap5/omap.h |3 ++-
drivers/mmc/omap_hsmmc.c | 26 ++
drivers/power/palmas.c | 25 -
include/configs/omap5_common.h |4
include/configs/omap5_uevm.h |5 -
include/palmas.h |6 +-
6 files changed, 49 insertions(+), 20 deletions(-)
[snip]
+ /* set LDO9 TWL6035 to 3V */
LDO9? TWL6035? If this function is used on the DRA7xx boards only (with
TPS659038), you should add some comment above.
Ok ll add the comment.
+ val = 0x2b; /* (3 - 0.9) * 20 + 1 */
Why not use definitions for the voltage? You could take them from
http://patchwork.ozlabs.org/patch/244103/ where some values are
defined.
Yes, Ill rebase this patch on top of your patch and use those defines.
Please be aware that my above mentioned patch has not been reviewed/
tested/acked/nacked/whatever by nobody (except possibly a quick look by
Nishanth Menon, who had some objections). I wrote it when bringing up a
custom OMAP5 board, and most probably it shall not go into mainline in
its current form, if ever. I gave it only as an example of how things
could be done cleaner. Feel free to use the code as you wish, but I'm
afraid that applying it as a patch to your tree and basing upon it might
run you into problems when you later sync with mainline.
Tom, your opinion?
+
+ if (palmas_i2c_write_u8(TPS659038_CHIP_ADDR, LDO1_VOLTAGE, val)) {
+ printf(tps659038: could not set LDO1 voltage\n);
+ return 1;
+ }
+
+ /* TURN ON LDO9 */
LDO9?
+ val = LDO_ON | LDO_MODE_SLEEP | LDO_MODE_ACTIVE;
Bit LDO_ON in all LDOx_CTRL Palmas registers is Read-Only (and reflects the
current status of the LDO). While it makes no harm to try writing to it, this
may be misleading about actual LDO operation, and anyway has no sense.
Yes, I see a similar update in your patch for LDO9. ll do the same for
LDO1 also.
But are you sure that the TPS659038 has the same LDOx_CTRL register layout
as the TWL6035/37? It belongs to the family, yes, but I don't have a
Register Manual for this chip... Hope you have checked.
Thanks
Lokesh
[snip]
Best regards,
Lubo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5] ARM: OMAP: I2C: New read, write and probe functions
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 require driver modification. - Rewritten i2c_read to operate correctly with all types of chips (old function could not read consistent data from some I2C slaves). - Optimised i2c_write. - New i2c_probe, performs write access vs read. The old probe could hang the system under certain conditions (e.g. unconfigured pads). - The read/write/probe functions try 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, checkpatch-clean. V4 changes: - New i2c_probe is built unconditionally, old code is removed. CONFIG_I2C_PROBE_WRITE is no longer needed. - Added a small delay to work around breakage in AM335X SPL. - Some whitespace and general formatting cleanup. 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. - Interrupts are enabled for OMAP243X and OMAP34XX only (where we don't have an irqstatus_raw register). 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 | 490 +++-- 1 file changed, 299 insertions(+), 191 deletions(-) Tested on 3 arm335x based boards, which one uses i2c in SPL code for getting ram parameters, so: Tested-by: Heiko Schocher h...@denx.de Many thanks for testing, to Tom as well (he did it on the Beagleboards, but for one of the older versions, V3 I believe, right?). When it comes to versions, I see that V1 and V2 are still listed in patchwork, probably because of slightly different wording of the subject: http://patchwork.ozlabs.org/patch/233823/ http://patchwork.ozlabs.org/patch/246204/ Could you or Tom clean this up, please? Thanks. Just one comment: Your patch has 9 checkpatch warnings which are all lines (printf strings) over 80 chars ... some with lines 110 characters ... I know, tom gave you a OK for this ... I am also unhappy with splitting a printf-string over 2 or more lines ... but we have this 80 characters rule ... Wolfgang, what do you think? Should we loosen this rule for printf-strings? Yes, I had the long strings splitted in the older versions, but then unrolled them back as per Tom's recommendation. IMHO, grep-ability is worth breaking this particular rule... But perhaps only for pure strings w/o format placeholders? I mean, strings could be splitted at the format parameters of printf/sprintf arguments. bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Best regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V5] ARM: OMAP: I2C: New read, write and probe functions
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 require driver modification.
- Rewritten i2c_read to operate correctly with all types of chips
(old function could not read consistent data from some I2C slaves).
- Optimised i2c_write.
- New i2c_probe, performs write access vs read. The old probe could
hang the system under certain conditions (e.g. unconfigured pads).
- The read/write/probe functions try 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, checkpatch-clean.
V4 changes:
- New i2c_probe is built unconditionally, old code is removed.
CONFIG_I2C_PROBE_WRITE is no longer needed.
- Added a small delay to work around breakage in AM335X SPL.
- Some whitespace and general formatting cleanup.
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.
- Interrupts are enabled for OMAP243X and OMAP34XX only (where we
don't have an irqstatus_raw register).
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 | 490 +++--
1 file changed, 299 insertions(+), 191 deletions(-)
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
index 54e9b15..ef38d71 100644
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -18,6 +18,20 @@
*
* Adapted for OMAP2420 I2C, r-woodru...@ti.com
*
+ * Copyright (c) 2013 Lubomir Popov lpo...@mm-sol.com, MM Solutions
+ * 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 require driver modification.
+ * - Rewritten i2c_read to operate correctly with all types of chips
+ * (old function could not read consistent data from some I2C slaves).
+ * - Optimized i2c_write.
+ * - New i2c_probe, performs write access vs read. The old probe could
+ * hang the system under certain conditions (e.g. unconfigured pads).
+ * - The read/write/probe functions try 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).
*/
#include common.h
@@ -31,8 +45,11 @@ DECLARE_GLOBAL_DATA_PTR;
#define I2C_TIMEOUT1000
+/* Absolutely safe for status update at 100 kHz I2C: */
+#define I2C_WAIT 200
+
static int wait_for_bb(void);
-static u16 wait_for_pin(void);
+static u16 wait_for_event(void);
static void flush_fifo(void);
/*
@@ -137,10 +154,14 @@ void i2c_init(int speed, int slaveadd)
/* own address */
writew(slaveadd, i2c_base-oa);
writew(I2C_CON_EN, i2c_base-con);
-
- /* have to enable intrrupts or OMAP i2c module doesn't work */
+#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX)
+ /*
+* Have to enable interrupts for OMAP2/3, these IPs don't have
+* an 'irqstatus_raw' register and we shall have to poll 'stat'
+*/
writew(I2C_IE_XRDY_IE | I2C_IE_RRDY_IE | I2C_IE_ARDY_IE |
- I2C_IE_NACK_IE | I2C_IE_AL_IE, i2c_base-ie);
+ I2C_IE_NACK_IE | I2C_IE_AL_IE, i2c_base-ie);
+#endif
udelay(1000);
flush_fifo();
writew(0x, i2c_base-stat);
@@ -150,88 +171,6 @@ void i2c_init(int speed, int slaveadd)
bus_initialized[current_bus] = 1;
}
-static int i2c_read_byte(u8 devaddr, u16 regoffset, u8 alen, u8 *value)
-{
- int i2c_error = 0;
- u16 status;
- int i = 2 - alen;
- u8 tmpbuf[2] = {(regoffset) 8, regoffset 0xff};
- u16 w;
-
- /* wait until bus not busy */
- if (wait_for_bb())
- return 1;
-
- /* one byte only */
- writew(alen, i2c_base-cnt);
- /* set slave address */
- writew(devaddr, i2c_base-sa);
- /* no stop bit needed here */
- writew(I2C_CON_EN | I2C_CON_MST | I2C_CON_STT |
- I2C_CON_TRX, i2c_base-con);
-
- /* send register offset */
- while (1) {
- status = wait_for_pin();
- if (status == 0 || status I2C_STAT_NACK) {
- i2c_error = 1;
- goto read_exit;
- }
- if (status I2C_STAT_XRDY) {
- w = tmpbuf[i
Re: [U-Boot] [PATCH v3] OMAP: I2C: New read, write and probe functions
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 with all types of chips (old function could not read consistent data from some I2C slaves). - Optimised i2c_write. - New i2c_probe, optionally selectable via CONFIG_I2C_PROBE_WRITE, performs write access vs read. The old probe could hang the system under certain conditions (e.g. unconfigured pads). - The read/write/probe functions try 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 With CONFIG_I2C_PROBE_WRITE set: Tested-by: Tom Rini tr...@ti.com on Beagleboard / Beagleboard xM 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 and caused a hang (interestingly, when called from regular u-boot, works fine). Fix is to add a small delay. Clocking and I2C speed should be identical between SPL and U-Boot, but probably are not; I did not have time to look with a scope, but don't have any other reasonable explanation. Whatever, now it is working. I shall submit the patch tonight. Would like as well to note that the current u-boot-ti/master (freshly cloned, no changes whatsoever) does not boot on the am335x-evm: U-Boot SPL 2013.04-11562-g47c6ea0 (May 31 2013 - 09:56:46) musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 ### ERROR ### Please RESET the board ### -- Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] OMAP: I2C: New read, write and probe functions
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 and caused a hang (interestingly, when called from regular u-boot, works fine). Fix is to add a small delay. Clocking and I2C speed should be identical between SPL and U-Boot, but probably are not; I did not have time to look with a scope, but don't have any other reasonable explanation. Whatever, now it is working. I shall submit the patch tonight. [snip] Just tested on Beaglebone, works fine as well. -- Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4] ARM: OMAP: I2C: New read, write and probe functions
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 require driver modification.
- Rewritten i2c_read to operate correctly with all types of chips
(old function could not read consistent data from some I2C slaves).
- Optimised i2c_write.
- New i2c_probe, performs write access vs read. The old probe could
hang the system under certain conditions (e.g. unconfigured pads).
- The read/write/probe functions try 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.
CONFIG_I2C_PROBE_WRITE is no longer needed.
- Added a small delay to work around breakage in AM335X SPL.
- Some whitespace and general formatting cleanup.
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.
- Interrupts are enabled for OMAP243X and OMAP34XX only (where we
don't have an irqstatus_raw register).
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 | 490 +++--
1 file changed, 300 insertions(+), 190 deletions(-)
mode change 100644 = 100755 drivers/i2c/omap24xx_i2c.c
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
old mode 100644
new mode 100755
index 54e9b15..5a1c74e
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -18,6 +18,20 @@
*
* Adapted for OMAP2420 I2C, r-woodru...@ti.com
*
+ * Copyright (c) 2013 Lubomir Popov lpo...@mm-sol.com, MM Solutions
+ * 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 require driver modification.
+ * - Rewritten i2c_read to operate correctly with all types of chips
+ * (old function could not read consistent data from some I2C slaves).
+ * - Optimized i2c_write.
+ * - New i2c_probe, performs write access vs read. The old probe could
+ * hang the system under certain conditions (e.g. unconfigured pads).
+ * - The read/write/probe functions try 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).
*/
#include common.h
@@ -31,8 +45,11 @@ DECLARE_GLOBAL_DATA_PTR;
#define I2C_TIMEOUT1000
+/* Absolutely safe for status update at 100 kHz I2C: */
+#define I2C_WAIT 200
+
static int wait_for_bb(void);
-static u16 wait_for_pin(void);
+static u16 wait_for_event(void);
static void flush_fifo(void);
/*
@@ -137,10 +154,14 @@ void i2c_init(int speed, int slaveadd)
/* own address */
writew(slaveadd, i2c_base-oa);
writew(I2C_CON_EN, i2c_base-con);
-
- /* have to enable intrrupts or OMAP i2c module doesn't work */
+#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX)
+ /*
+* Have to enable interrupts for OMAP2/3, these IPs don't have
+* an 'irqstatus_raw' register and we shall have to poll 'stat'
+*/
writew(I2C_IE_XRDY_IE | I2C_IE_RRDY_IE | I2C_IE_ARDY_IE |
I2C_IE_NACK_IE | I2C_IE_AL_IE, i2c_base-ie);
+#endif
udelay(1000);
flush_fifo();
writew(0x, i2c_base-stat);
@@ -150,88 +171,6 @@ void i2c_init(int speed, int slaveadd)
bus_initialized[current_bus] = 1;
}
-static int i2c_read_byte(u8 devaddr, u16 regoffset, u8 alen, u8 *value)
-{
- int i2c_error = 0;
- u16 status;
- int i = 2 - alen;
- u8 tmpbuf[2] = {(regoffset) 8, regoffset 0xff};
- u16 w;
-
- /* wait until bus not busy */
- if (wait_for_bb())
- return 1;
-
- /* one byte only */
- writew(alen, i2c_base-cnt);
- /* set slave address */
- writew(devaddr, i2c_base-sa);
- /* no stop bit needed here */
- writew(I2C_CON_EN | I2C_CON_MST | I2C_CON_STT |
- I2C_CON_TRX, i2c_base-con);
-
- /* send register offset */
- while (1) {
- status = wait_for_pin();
- if (status == 0 || status I2C_STAT_NACK) {
- i2c_error = 1;
- goto read_exit;
- }
- if (status I2C_STAT_XRDY) {
- w = tmpbuf[i++];
-#if !(defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX) || \
- defined
Re: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1
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 ++-
drivers/mmc/omap_hsmmc.c | 26 ++
drivers/power/palmas.c | 25 -
include/configs/omap5_common.h |4
include/configs/omap5_uevm.h |5 -
include/palmas.h |6 +-
6 files changed, 49 insertions(+), 20 deletions(-)
[snip]
diff --git a/drivers/power/palmas.c b/drivers/power/palmas.c
index 09c832d..1bcff52 100644
--- a/drivers/power/palmas.c
+++ b/drivers/power/palmas.c
@@ -28,7 +28,7 @@ void palmas_init_settings(void)
return;
}
-int palmas_mmc1_poweron_ldo(void)
+int palmas_mmc1_poweron_ldo9(void)
{
u8 val = 0;
@@ -50,3 +50,26 @@ int palmas_mmc1_poweron_ldo(void)
return 0;
}
+
+int palmas_mmc1_poweron_ldo1(void)
+{
+ u8 val = 0;
+
+ /* set LDO9 TWL6035 to 3V */
LDO9? TWL6035? If this function is used on the DRA7xx boards only (with
TPS659038), you should add some comment above.
+ val = 0x2b; /* (3 - 0.9) * 20 + 1 */
Why not use definitions for the voltage? You could take them from
http://patchwork.ozlabs.org/patch/244103/ where some values are
defined.
+
+ if (palmas_i2c_write_u8(TPS659038_CHIP_ADDR, LDO1_VOLTAGE, val)) {
+ printf(tps659038: could not set LDO1 voltage\n);
+ return 1;
+ }
+
+ /* TURN ON LDO9 */
LDO9?
+ val = LDO_ON | LDO_MODE_SLEEP | LDO_MODE_ACTIVE;
Bit LDO_ON in all LDOx_CTRL Palmas registers is Read-Only (and reflects the
current status of the LDO). While it makes no harm to try writing to it, this
may be misleading about actual LDO operation, and anyway has no sense.
+
+ if (palmas_i2c_write_u8(TPS659038_CHIP_ADDR, LDO1_CTRL, val)) {
+ printf(tps659038: could not turn on LDO1\n);
+ return 1;
+ }
+
[snip]
/* I2C chip addresses */
#define PALMAS_CHIP_ADDR 0x48
+#define TPS659038_CHIP_ADDR 0x58
Now we have a mess again. The files were recently renamed from twl6035.x
to palmas.x, implying that palmas is the generic family name of a series
of PMICs. Having TPS659038_CHIP_ADDR above is OK, but then we should have
TWL603X_CHIP_ADDR instead of PALMAS_CHIP_ADDR.
Best regards,
Lubomir
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] OMAP: I2C: New read, write and probe functions
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 consistent data from some I2C slaves). - Optimised i2c_write. - New i2c_probe, optionally selectable via CONFIG_I2C_PROBE_WRITE, performs write access vs read. The old probe could hang the system under certain conditions (e.g. unconfigured pads). - The read/write/probe functions try 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 With CONFIG_I2C_PROBE_WRITE set: Tested-by: Tom Rini tr...@ti.com on Beagleboard / Beagleboard xM So lets just go with the write probe always being on again. Now, when I git am'd I saw some whitespace problems, so please make sure v4 is checkpatch clean. And note that printf(Long than 80 char wide, a, b) is OK and expected to NOT break the string (but do align the args). OK, shall do it tonight. I see a minor problem however: if we are not going to support all OMAP2 chips (the 2420 in particular), isn't it somewhat misleading to keep the driver named omap24xx_i2c? Letting you decide... -- Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] OMAP: I2C: New read, write and probe functions
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 function could not read consistent data from some I2C slaves). - Optimised i2c_write. - New i2c_probe, optionally selectable via CONFIG_I2C_PROBE_WRITE, performs write access vs read. The old probe could hang the system under certain conditions (e.g. unconfigured pads). - The read/write/probe functions try 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 With CONFIG_I2C_PROBE_WRITE set: Tested-by: Tom Rini tr...@ti.com on Beagleboard / Beagleboard xM But, crap, breaks am335x_evm (and probably beaglebones, etc). I'll dig into this more to see if I can spot something obvious tomorrow. OK, holding off. And thanks for testing. -- Tom -- Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] OMAP: I2C: New read, write and probe functions
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 function could not read consistent data from some I2C slaves). - Optimised i2c_write. - New i2c_probe, optionally selectable via CONFIG_I2C_PROBE_WRITE, performs write access vs read. The old probe could hang the system under certain conditions (e.g. unconfigured pads). - The read/write/probe functions try 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 With CONFIG_I2C_PROBE_WRITE set: Tested-by: Tom Rini tr...@ti.com on Beagleboard / Beagleboard xM But, crap, breaks am335x_evm (and probably beaglebones, etc). I'll dig into this more to see if I can spot something obvious tomorrow. How does it actually break? Does not build, or I2C is not working, or what? If I2C is not working, could you try changing the condition #if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX) to #if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX) || defined(CONFIG_AM33XX) found in 3 places in driver (lines 155, 554, 585) and test again? Thanks, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot OMAP issues
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 of unconfigured bus). Should I submit it, what are you plans in respect to I2C? Yes, please submit the i2c driver changes, I shall take them in some form or another soon. OK, can even try to do this now from here. Submitted - http://patchwork.ozlabs.org/patch/246204/ Looking at it again, I tend to dislike this solution more and more. Ugly ifdef-ed code. Couldn't we reconsider again adding this as a new driver, built for those SoCs that are confirmed to work (OMAP4 and 5 for sure)? Lets take another swag at this. Update the functions for everyone and I'll get some omap3 testing done. OK, but you shall have to either entirely remove the ifdefs and the old functions, or edit the #if defined(CONFIG_OMAP)... conditions to include the SoC types you are testing on. Yeah. If you don't repost the patch with just always using the new functions, I'll do some local yanking out. I kinda hope to pencil that in as my task for tomorrow. Thanks :) OK, I shall do it now. Does it matter if I base on u-boot-ti, or on mainline? Guess not... Regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] OMAP: I2C: New read, write and probe functions
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 consistent data from some I2C slaves).
- Optimised i2c_write.
- New i2c_probe, optionally selectable via CONFIG_I2C_PROBE_WRITE,
performs write access vs read. The old probe could hang the system
under certain conditions (e.g. unconfigured pads).
- The read/write/probe functions try 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
---
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.
- Interrupts are enabled for OMAP243X and OMAP34XX only (where we
don't have an irqstatus_raw register).
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 | 482 ++---
1 file changed, 326 insertions(+), 156 deletions(-)
mode change 100644 = 100755 drivers/i2c/omap24xx_i2c.c
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
old mode 100644
new mode 100755
index 54e9b15..deac0ec
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -18,6 +18,18 @@
*
* Adapted for OMAP2420 I2C, r-woodru...@ti.com
*
+ * Copyright (c) 2013 Lubomir Popov lpo...@mm-sol.com, MM Solutions
+ * New i2c_read, i2c_write and i2c_probe functions, 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 consistent data from some I2C slaves).
+ * - Optimized i2c_write.
+ * - New i2c_probe, optionally selectable via CONFIG_I2C_PROBE_WRITE,
+ * performs write access vs read. The old probe could hang the system
+ * under certain conditions (e.g. unconfigured pads).
+ * - The read/write/probe functions try to identify unconfigured bus.
+ * - Status functions now read irqstatus_raw as per TRM guidelines.
+ * - Driver now supports up to I2C5 (OMAP5).
*/
#include common.h
@@ -31,8 +43,11 @@ DECLARE_GLOBAL_DATA_PTR;
#define I2C_TIMEOUT1000
+/* Absolutely safe for status update at 100 kHz I2C: */
+#define I2C_WAIT 200
+
static int wait_for_bb(void);
-static u16 wait_for_pin(void);
+static u16 wait_for_event(void);
static void flush_fifo(void);
/*
@@ -137,10 +152,14 @@ void i2c_init(int speed, int slaveadd)
/* own address */
writew(slaveadd, i2c_base-oa);
writew(I2C_CON_EN, i2c_base-con);
-
- /* have to enable intrrupts or OMAP i2c module doesn't work */
+#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX)
+ /*
+* Have to enable interrupts for OMAP2/3, these IPs don't have
+* an 'irqstatus_raw' register and we shall have to poll 'stat'
+*/
writew(I2C_IE_XRDY_IE | I2C_IE_RRDY_IE | I2C_IE_ARDY_IE |
I2C_IE_NACK_IE | I2C_IE_AL_IE, i2c_base-ie);
+#endif
udelay(1000);
flush_fifo();
writew(0x, i2c_base-stat);
@@ -150,88 +169,6 @@ void i2c_init(int speed, int slaveadd)
bus_initialized[current_bus] = 1;
}
-static int i2c_read_byte(u8 devaddr, u16 regoffset, u8 alen, u8 *value)
-{
- int i2c_error = 0;
- u16 status;
- int i = 2 - alen;
- u8 tmpbuf[2] = {(regoffset) 8, regoffset 0xff};
- u16 w;
-
- /* wait until bus not busy */
- if (wait_for_bb())
- return 1;
-
- /* one byte only */
- writew(alen, i2c_base-cnt);
- /* set slave address */
- writew(devaddr, i2c_base-sa);
- /* no stop bit needed here */
- writew(I2C_CON_EN | I2C_CON_MST | I2C_CON_STT |
- I2C_CON_TRX, i2c_base-con);
-
- /* send register offset */
- while (1) {
- status = wait_for_pin();
- if (status == 0 || status I2C_STAT_NACK) {
- i2c_error = 1;
- goto read_exit;
- }
- if (status I2C_STAT_XRDY) {
- w = tmpbuf[i++];
-#if !(defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX) || \
- defined(CONFIG_OMAP44XX) || defined(CONFIG_AM33XX) || \
- defined(CONFIG_OMAP54XX))
- w |= tmpbuf[i++] 8;
-#endif
- writew(w, i2c_base-data);
- writew(I2C_STAT_XRDY, i2c_base-stat);
- }
- if (status I2C_STAT_ARDY) {
- writew(I2C_STAT_ARDY, i2c_base-stat);
- break;
- }
- }
-
- /* set slave address */
- writew
[U-Boot] [PATCH] OMAP5: Fix bug in omap5_es1_prcm struct
The newly introduced function setup_warmreset_time(), called
from within prcm_init(), tries to write to the rsttime OMAP5
register. The struct member holding this register's address,
prm_rsttime, is however initialized for OMAP5 ES2.0 only.
On ES1.0 devices this uninitialized value causes a second
(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 a/arch/arm/cpu/armv7/omap5/prcm-regs.c
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index e9f6a32..f29ac77 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -298,6 +298,7 @@ struct prcm_regs const omap5_es1_prcm = {
.cm_wkupaon_io_srcomp_clkctrl = 0x4ae07898,
.prm_rstctrl = 0x4ae07b00,
.prm_rstst = 0x4ae07b04,
+ .prm_rsttime = 0x4ae07c08,
.prm_vc_val_bypass = 0x4ae07ba0,
.prm_vc_cfg_i2c_mode = 0x4ae07bb4,
.prm_vc_cfg_i2c_clk = 0x4ae07bb8,
--
1.7.12.4 (Apple Git-37)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] OMAP5: Fix bug in omap5_es1_prcm struct
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
devices this uninitialized value causes a second (warm) 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 a/arch/arm/cpu/armv7/omap5/prcm-regs.c
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index e9f6a32..f29ac77 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -298,6 +298,7 @@ struct prcm_regs const omap5_es1_prcm = {
.cm_wkupaon_io_srcomp_clkctrl = 0x4ae07898,
.prm_rstctrl = 0x4ae07b00,
.prm_rstst = 0x4ae07b04,
+ .prm_rsttime = 0x4ae07b08,
.prm_vc_val_bypass = 0x4ae07ba0,
.prm_vc_cfg_i2c_mode = 0x4ae07bb4,
.prm_vc_cfg_i2c_clk = 0x4ae07bb8,
--
1.7.12.4 (Apple Git-37)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] OMAP4/5: I2C: New read, write and probe functions
Tested and built for 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 consistent data from some I2C slaves).
- Optimised i2c_write.
- New i2c_probe, optionally selectable via CONFIG_I2C_PROBE_WRITE,
performs write access vs read. The old probe could hang the system
under certain conditions.
- The read/write/probe functions try to identify unconfigured bus.
- Status functions now read irqstatus_raw as per TRM guidelines.
- Driver now supports up to I2C5 (OMAP5).
Signed-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 changed, 387 insertions(+), 27 deletions(-)
mode change 100644 = 100755 drivers/i2c/omap24xx_i2c.c
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
old mode 100644
new mode 100755
index 54e9b15..4294701
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -18,6 +18,19 @@
*
* Adapted for OMAP2420 I2C, r-woodru...@ti.com
*
+ * Copyright (c) 2013 Lubomir Popov lpo...@mm-sol.com, MM Solutions
+ * New i2c_read, i2c_write and i2c_probe functions, tested and built
+ * for 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 consistent data from some I2C slaves).
+ * - Optimized i2c_write.
+ * - New i2c_probe, optionally selectable via CONFIG_I2C_PROBE_WRITE,
+ * performs write access vs read. The old probe could hang the system
+ * under certain conditions.
+ * - The read/write/probe functions try to identify unconfigured bus.
+ * - Status functions now read irqstatus_raw as per TRM guidelines.
+ * - Driver now supports up to I2C5 (OMAP5).
*/
#include common.h
@@ -31,8 +44,15 @@ DECLARE_GLOBAL_DATA_PTR;
#define I2C_TIMEOUT1000
+#if defined(CONFIG_OMAP44XX) || defined(CONFIG_OMAP54XX)
+/* Absolutely safe for status update at 100 kHz I2C: */
+#define I2C_WAIT 200
+#else
+#define I2C_WAIT 1000
+#endif
+
static int wait_for_bb(void);
-static u16 wait_for_pin(void);
+static u16 wait_for_event(void);
static void flush_fifo(void);
/*
@@ -150,6 +170,7 @@ void i2c_init(int speed, int slaveadd)
bus_initialized[current_bus] = 1;
}
+#if !(defined(CONFIG_OMAP44XX) || defined(CONFIG_OMAP54XX))
static int i2c_read_byte(u8 devaddr, u16 regoffset, u8 alen, u8 *value)
{
int i2c_error = 0;
@@ -172,7 +193,7 @@ static int i2c_read_byte(u8 devaddr, u16 regoffset, u8
alen, u8 *value)
/* send register offset */
while (1) {
- status = wait_for_pin();
+ status = wait_for_event();
if (status == 0 || status I2C_STAT_NACK) {
i2c_error = 1;
goto read_exit;
@@ -204,7 +225,7 @@ static int i2c_read_byte(u8 devaddr, u16 regoffset, u8
alen, u8 *value)
/* receive data */
while (1) {
- status = wait_for_pin();
+ status = wait_for_event();
if (status == 0 || status I2C_STAT_NACK) {
i2c_error = 1;
goto read_exit;
@@ -231,6 +252,7 @@ read_exit:
writew(0, i2c_base-cnt);
return i2c_error;
}
+#endif
static void flush_fifo(void)
{ u16 stat;
@@ -255,6 +277,65 @@ static void flush_fifo(void)
}
}
+#if (defined(CONFIG_OMAP44XX) || defined(CONFIG_OMAP54XX)) \
+ defined(CONFIG_I2C_PROBE_WRITE)
+/*
+ * i2c_probe: Use write access. Allows to identify addresses that are
+ *write-only (like the config register of dual-port EEPROMs)
+ */
+int i2c_probe(uchar chip)
+{
+ u16 status;
+ int res = 1; /* default = fail */
+
+ if (chip == readw(i2c_base-oa))
+ return res;
+
+ /* Wait until bus is free */
+ if (wait_for_bb())
+ return res;
+
+ /* No data transfer, slave addr only */
+ writew(0, i2c_base-cnt);
+ /* set slave address */
+ writew(chip, i2c_base-sa);
+ /* stop bit needed here */
+ writew(I2C_CON_EN | I2C_CON_MST | I2C_CON_STT | I2C_CON_TRX |
+ I2C_CON_STP, i2c_base-con);
+
+ status = wait_for_event();
+
+ if ((status ~I2C_STAT_XRDY) == 0 || (status I2C_STAT_AL)) {
+ /*
+* With current high-level command implementation, notifying
+* the user shall flood the console with 127 messages. If
+* silent exit is desired upon unconfigured bus, remove the
+* following 'if' section:
+*/
+ if (status == I2C_STAT_XRDY)
+ printf(i2c_probe: pads on bus %d
Re: [U-Boot] [PATCH RFC] OMAP5: uEVM: Enable USB EHCI functionality (preliminary, not tested)
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, I have been trying to get the USB working on omap5 uEVM yesterday. In addition to your code, I added the changes necessary to pinmux the 79 and 80 GPIOS correctly, but it does not seem to work. I suspect there is something else missing than simply USB specific bits, because when the ethernet phy is supposedly out of reset, the ethernet leds keep turned off. I was thinking about checking the PMIC registers. PMIC wouldn't be related. Hi, My idea was that if the ethernet chip does not power up, maybe it is because some LDO or SMPS needs to be powered on. The board documentation says for some LDOs that they are enabled on boot and does not say for others, so that may be because they need to be enabled. Both USB devices are powered by VCC_3V3_MAIN, provided by an external SMPS chip (U3). With the default configuration of the uEVM, this SMPS turns on whenever DC wall power is present; the other option - control by the PMIC SYSEN1 output, has no relation to software as well (SYSEN1 is driven by the PMIC power-on/off sequencer, which is burnt into the PMIC EPROM. Upon power-on it goes high at the very beginning of the sequence). So, unfortunately, this could not be the cause. Regarding the Ethernet LEDs, as far as I remember, they didn't light up at all, although Ethernet worked. The smsc95xx driver in u-boot supports the LAN9730 in compatibility mode and probably does not setup LED operation properly. Did you pull the current u-boot master and then apply the following patches before testing? Eager to know ;) http://patchwork.ozlabs.org/patch/232742/ http://patchwork.ozlabs.org/patch/244100/ I was working with u-boot-ti master, applied all the patches, and it still does not seem to work. I just tried the u-boot master branch but it fails to compile for omap5_uevm. I think mainline u-boot master still lacks another vital patch for OMAP5 USB, which has been applied to u-boot-ti only (this is commit 2bcc785a1e8ffd3783c2116837fb4b4866a70cef). So please stay with the ti branch for now. Don't know what to say; it's a pity that I don't have the hardware at hand. One more thing that I would suggest to try: remove the patch from ehci-hcd.c that calls the HSIC device reset function for OMAP5. The essence is one line, a function call: omap5_ehci_hsic_reset_device(le16_to_cpu(req-index)); Just comment it out. It is fairly possible that on ES2.0 this workaround is not needed anymore (although I don't recall anything on the subject in the Silicon Errata docs). I have tested on ES1.0 only, so it has to be verified that this patch doesn't have a negative impact on ES2.0. Regards. -- Gilles. Best regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] OMAP5: uEVM: Enable USB EHCI functionality (preliminary, not tested)
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, and to the OMAP5 clock register definitions. Hi Lubomir, I have been trying to get the USB working on omap5 uEVM yesterday. In addition to your code, I added the changes necessary to pinmux the 79 and 80 GPIOS correctly, but it does not seem to work. I suspect there is something else missing than simply USB specific bits, because when the ethernet phy is supposedly out of reset, the ethernet leds keep turned off. I was thinking about checking the PMIC registers. PMIC wouldn't be related. Hi, My idea was that if the ethernet chip does not power up, maybe it is because some LDO or SMPS needs to be powered on. The board documentation says for some LDOs that they are enabled on boot and does not say for others, so that may be because they need to be enabled. Both USB devices are powered by VCC_3V3_MAIN, provided by an external SMPS chip (U3). With the default configuration of the uEVM, this SMPS turns on whenever DC wall power is present; the other option - control by the PMIC SYSEN1 output, has no relation to software as well (SYSEN1 is driven by the PMIC power-on/off sequencer, which is burnt into the PMIC EPROM. Upon power-on it goes high at the very beginning of the sequence). So, unfortunately, this could not be the cause. Regarding the Ethernet LEDs, as far as I remember, they didn't light up at all, although Ethernet worked. The smsc95xx driver in u-boot supports the LAN9730 in compatibility mode and probably does not setup LED operation properly. Reading the schematics, it seems to me that the ethernet reset arrives on a component using 1.8V which if I am not mistaken comes from the PMIC SMPS7. Well, this (1.8 V) is the main I/O supply of the OMAP and most peripherals; if it were not OK, the board wouldn't work at all. -- Gilles. BR Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] OMAP5: uEVM: Enable USB EHCI functionality (preliminary, not tested)
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 ES1.0 U-Boot SPL 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17) OMAP5430 ES1.0 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17) [snip] Also please notice that the SPL now seems to be executed twice (on both boards). This was not the case until recently, at least with the mainline. Anything to do with all those relocation discussions/patches? Can you bisect and see when something changed? It looks like it's printing the same string twice, not loading SPL loading SPL loading U-Boot, but I could be wrong.. I tried SD and EMMC boot on the latest mainline on my 5432 ES2.0 and did not see any issue. What boot are you trying ? The TI tree - see above. This is where Tom applied the USB patches. Unfortunately I cannot be of any help today - I'm sick and at home. U-Boot SPL 2013.04-00237-g9d32686 (May 17 2013 - 10:54:15) OMAP5432 ES2.0 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.04-00237-g9d32686 (May 17 2013 - 10:54:15) CPU : OMAP5432 ES2.0 Board: OMAP5430 EVM I2C: ready DRAM: 2 GiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment In:serial Out: serial Err: serial Hit any key to stop autoboot: 0 OMAP5430 EVM # Regards, Sricharan Regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] OMAP5: uEVM: Fix pinmux for USB support
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 modification at all and has to be carefully fixed.
This patch addresses the USB reset function only.
board/ti/omap5_uevm/mux_data.h |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/board/ti/omap5_uevm/mux_data.h b/board/ti/omap5_uevm/mux_data.h
index a82795d..054ada6 100644
--- a/board/ti/omap5_uevm/mux_data.h
+++ b/board/ti/omap5_uevm/mux_data.h
@@ -47,8 +47,7 @@ const struct pad_conf_entry core_padconf_array_essential[] = {
{SDCARD_DATA3, (PTU | IEN | M0)}, /* SDCARD_DATA3*/
{UART3_RX_IRRX, (PTU | IEN | M0)}, /* UART3_RX_IRRX*/
{UART3_TX_IRTX, (M0)},/* UART3_TX_IRTX*/
- {USBB1_HSIC_STROBE, (PTU | IEN | M0)},/* USBB1_HSIC_STROBE */
- {USBB1_HSIC_DATA, (PTU | IEN | M0)},/* USBB1_HSIC_DATA */
+
{USBB2_HSIC_STROBE, (PTU | IEN | M0)},/* USBB2_HSIC_STROBE */
{USBB2_HSIC_DATA, (PTU | IEN | M0)},/* USBB2_HSIC_DATA */
{USBB3_HSIC_STROBE, (PTU | IEN | M0)},/* USBB3_HSIC_STROBE*/
@@ -57,6 +56,8 @@ const struct pad_conf_entry core_padconf_array_essential[] = {
{USBD0_HS_DM, (IEN | M0)}, /* USBD0_HS_DM */
{USBD0_SS_RX, (IEN | M0)}, /* USBD0_SS_RX */
+ {HSI2_ACWAKE, (PTD | M6)},/* GPIO3_79: ETH_nRST */
+ {HSI2_CAFLAG, (PTD | M6)},/* GPIO3_80: H_USBH_NRESET */
};
const struct pad_conf_entry wkup_padconf_array_essential[] = {
@@ -114,8 +115,6 @@ const struct pad_conf_entry
core_padconf_array_non_essential[] = {
{HSI2_CAREADY, (IEN | M0)},/* HSI2_CAREADY */
{HSI2_ACREADY, (OFF_EN | M0)},/* HSI2_ACREADY */
{HSI2_CAWAKE, (IEN | PTD | M0)},/* HSI2_CAWAKE */
- {HSI2_ACWAKE, (M0)},/* HSI2_ACWAKE */
- {HSI2_CAFLAG, (IEN | PTD | M0)},/* HSI2_CAFLAG */
{HSI2_CADATA, (IEN | PTD | M0)},/* HSI2_CADATA */
{HSI2_ACFLAG, (M0)},/* HSI2_ACFLAG */
{HSI2_ACDATA, (M0)},/* HSI2_ACDATA */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] OMAP5: uEVM: Enable USB EHCI functionality (preliminary, not tested)
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 is in http://patchwork.ozlabs.org/patch/244233/ Please see comments inline below. On 16/05/13 01:06, Tom Rini wrote: 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 hardware (also known as OMAP5432 ES2.0 PandaBoard5) - the GPIOs that I used used for HSIC reset correspond to that board. Looking at mux_data.h however, I'm somewhat concerned. All the uevm board files are inherited from the sEVM, which is a very different hardware platform, and I'm afraid that only changing the file names might not be sufficient. The patch is not tested yet due to lack of hardware. Tom, I'm hoping for your assistance. OK, I applied: $ git log --oneline master.. 93460ef OMAP4/5: Add USB EHCI support d18c49c OMAP5: Enable USB Ethernet support with LAN9730 15a4481 OMAP5: Enable access to auxclk registers f307fc2 OMAP5: Power: Add more functionality to Palmas driver efdf00c OMAP5: uEVM: Enable USB EHCI functionality (preliminary, not tested) And added: +#define CONFIG_USB_ULPI +#define CONFIG_USB_ULPI_VIEWPORT_OMAP to include/configs/omap5_uevm.h Actually not needed at all for this board - it does not have any ULPI PHYs. We shall just get dead code. And usb start/usb rescan don't see any devices. OMAP5432 uEVM # usb start (Re)start USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) found Cable was plugged into the eth and a storage device was also plugged in. I suspect that we need to set CONFIG_OMAP_EHCI_PHY1_RESET_GPIO / CONFIG_OMAP_EHCI_PHY2_RESET_GPIO. I'm looking around for the schematic so I can try and find that out. No. This is for ULPI PHY reset only, we are using CONFIG_OMAP_HSIC_PORT2_RESET_GPIO and CONFIG_OMAP_HSIC_PORT3_RESET_GPIO for the HSIC devices. The problem is that these pads were not configured to GPIO mode. Above patch fixes this. Best regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] OMAP5: uEVM: Enable USB EHCI functionality (preliminary, not tested)
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 yesterday. In addition to your code, I added the changes necessary to pinmux the 79 and 80 GPIOS correctly, but it does not seem to work. I suspect there is something else missing than simply USB specific bits, because when the ethernet phy is supposedly out of reset, the ethernet leds keep turned off. I was thinking about checking the PMIC registers. PMIC wouldn't be related. Did you pull the current u-boot master and then apply the following patches before testing? Eager to know ;) http://patchwork.ozlabs.org/patch/232742/ http://patchwork.ozlabs.org/patch/244100/ Regards. Best regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] OMAP5: uEVM: Enable USB EHCI functionality (preliminary, not tested)
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 is in http://patchwork.ozlabs.org/patch/244233/ No change. Please see comments inline below. Ah right, thought so after reading over the SRM. I found here a couple of old uEVMs (the old 750-2617 board type with OMAP5432 ES1.0 and the old DDR3 power scheme). One was HS, so of no use directly (no time to play with image signing). On the GP, I get the following: U-Boot SPL 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:18:35) OMAP5432 ES1.0 U-Boot SPL 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:18:35) OMAP5432 ES1.0 SDRAM: identified size not same as expected size identified: 4 expected: 4000 OMAP SD/MMC: 0 spl: fat register err - -1 ### ERROR ### Please RESET the board ### reset U-Boot SPL 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:18:35) OMAP5432 ES1.0 U-Boot SPL 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:18:35) OMAP5432 ES1.0 SDRAM: identified size not same as expected size identified: 4 expected: 4000 OMAP SD/MMC: 0 spl: fat register err - -1 ### ERROR ### Please RESET the board ### ... 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 (May 16 2013 - 16:14:17) OMAP5430 ES1.0 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17) CPU : OMAP5430 ES1.0 Board: MM Solutions SOM5 EVB I2C: ready DRAM: 2 GiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment In:serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0 mmc0 is current device reading boot.scr 109 bytes read in 3 ms (35.2 KiB/s) Running bootscript from mmc0 ... ## Executing script at 8200 ** File not found /boot/zImage ** SOM5_EVB # usb start (Re)start USB... USB0: 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, 98mA) | USB Mass Storage Device 6fc59c7217b150 | +-3 Hub (480 Mb/s, 2mA) | | | +-4 Mass Storage (480 Mb/s, 96mA) | |Generic Ultra Fast Media Reader 00264001 | | | +-5 Mass Storage (480 Mb/s, 200mA) | FSC MEMORYBIRD USB2 C157040817120315AA | +-6 Vendor specific (480 Mb/s, 500mA) SOM5_EVB # I guess something at very low level mem init does not match the 5432 ES1.0 or the DDRs. So unfortunately I can't get to U-Boot and test USB. Also please notice that the SPL now seems to be executed twice (on both boards). This was not the case until recently, at least with the mainline. Anything to do with all those relocation discussions/patches? Best regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] OMAP5: uEVM: Enable USB EHCI functionality (preliminary, not tested)
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 (May 16 2013 - 16:14:17) OMAP5430 ES1.0 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17) [snip] Also please notice that the SPL now seems to be executed twice (on both boards). This was not the case until recently, at least with the mainline. Anything to do with all those relocation discussions/patches? Can you bisect and see when something changed? It looks like it's printing the same string twice, not loading SPL loading SPL loading U-Boot, but I could be wrong.. Well, if I go to work tomorrow - I think I got the flu today and am feeling really sick this evening. -- Tom L. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] OMAP5: Power: Add more functionality to Palmas driver
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 used by my board only. I am at a loss why one would need twl6040 powered on in u-boot. 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 it is #ifdef-ed anyway). Signed-off-by: Lubomir Popov lpo...@mm-sol.com --- V2 aligns to changed PMIC name (and file names accordingly) from twl6035 to Palmas and is based on current u-boot-ti master. Regards, Lubomir ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] OMAP5: Power: Add more functionality to Palmas driver
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 it is #ifdef-ed anyway). Right, and you need u-boot modified to do validation? I think either such code should stay out of tree, or be validated by expicit i2c commands (which already is supported) OR tested by virtual regulator consumer in linux ;) I dont think we should make u-boot an OS. just my 2 cents. my rule of thumb is: if it is not needed for boot, do it elsewhere other than bootloader. Yes, TI has omapboot, just a bootloader. I think that U-Boot, on the other hand, has become a quite powerfull tool, with a lot of useful functionality, at least for me as a hardware guy. But of course, if the community thinks of it as of a bootloader only, I give up. ;) Regards, NM Best regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
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 currently busy with other work; on the other hand, careful rebasing shall require some time, especially the Palmas stuff. What would be the deadline for a V2 submission? Meanwhile could you please have a look at the (already old) http://patchwork.ozlabs.org/patch/232743/? A simple patch, shall be needed if we enable USB (for the uEVM along with our board). In general, what are your plans regarding USB (.../patch/232742/)? Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do you have a patch around for uEVM still? Not yet (didn't have the opportunity to test, although some uEVMs should be around at MMS). As you know, a patch shall be needed in the uEVM board file along with the common USB stuff. Yeah, I can test it as well if you write it up, and may find the time if you point me in the right direction. And again on I2C (.../patch/233823/): what is you final opinion? I'm confident that this patch is a major improvement for OMAP4/5 at least. I'm inclined to go with it, just need to mentally unswap the i2c notes in my brain and think it over one more time. Just applied 233823 to current u-boot-ti master. Works fine. OK, thanks. [snip] + * TODO: Replace this ugly hardcoding with proper defines + */ + writel(0x0100, 0x4ae0a310); Again, do please. This should be (*scrm)-auxclk0. The problem is that the omap5_scrm_regs struct (holding the auxclk0 member) has to be defined somewhere in the common OMAP5 headers. Sricharan? Or should I hack around? Add it to the most likely struct in the headers. The entire struct (I call it omap5_scrm_regs in theory, similar to the corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of course I could define only the member that I need, but I guess it is a (responsible) TI job to define hardware descriptors. Or I'm wrong? Please advise. If I have time, I could do it myself - it's some 27 registers, almost identical to the OMAP4, and should go into arch/arm/include/asm/arch-omap5/clocks.h. Whomever uses / needs it should do it. I gave the TRM a quick read and I don't see any conflicts per-se just some reserved areas being named and vice versa. So rename it to omap_scrm_regs and move to asm/omap_common.h. Thanks! I would argue that this is not very appropriate. Those regs that are reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; on the other hand the OMAP5 has some modem clock regs that are reserved on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 and below? We don't need to use ifdefs since there's no conflicts, things are either reserved in one case and used in the other. And we can make sure we don't try and use the omap5 bits on omap4 and vice versa. I don't see scrm in the first omap3 TRM I pulled up, so we don't need to worry there. Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h file and I have already done the same for OMAP5 by analogy. I must admit however that this approach does not correspond to the latest way by which groups of OMAP hardware regs are defined, prcm in particular - a struct in omap_common.h, holding only the required regs, no padding and such garbage, and an init with the physical addresses in a .c file for the particular SoC (prcm-regs.c). But still the Panda board, for example, uses the old way for scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and lazy ;) ). Yes, I'm OK starting off with moving things into omap_common.h as-is and then updating them a bit later ala pcrm-regs.c. I am sorry for the very late response on this. Now then, why not add this register in to omap5_es2_prcm ??. That is how the TRM sees it as well.. Of course, this is cleanup stuff for OMAP4 panda as you pointed out.. Yes, you are right in respect to fluent software integration and consistency with current implementation. My only concern is that from architectural point of view the SCRM, although related to the PRCM, is a separate module (described correspondingly as such in the TRM). If we go this way, the SCRM regs shall have to be referenced via the prcm pointer: (*prcm)-x, and this might be confusing. I'm OK to do it as above, that is, add the SCRM regs (for both OMAP4 and OMAP5) to the prcm_regs declaration in omap_common.h, and the required init to the appropriate omap5_esx_prcm in prcm-regs.c, but would suggest that for improved clarity the SCRM register names, as they now exist in .../arch-omap4/clocks.h, start with a scrm_ prefix. Alternatively, a new scrm_regs struct could be declared in omap_common.h, along with the appropriate pointers
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
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, 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 currently busy with other work; on the other hand, careful rebasing shall require some time, especially the Palmas stuff. What would be the deadline for a V2 submission? Meanwhile could you please have a look at the (already old) http://patchwork.ozlabs.org/patch/232743/? A simple patch, shall be needed if we enable USB (for the uEVM along with our board). In general, what are your plans regarding USB (.../patch/232742/)? Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do you have a patch around for uEVM still? Not yet (didn't have the opportunity to test, although some uEVMs should be around at MMS). As you know, a patch shall be needed in the uEVM board file along with the common USB stuff. Yeah, I can test it as well if you write it up, and may find the time if you point me in the right direction. And again on I2C (.../patch/233823/): what is you final opinion? I'm confident that this patch is a major improvement for OMAP4/5 at least. I'm inclined to go with it, just need to mentally unswap the i2c notes in my brain and think it over one more time. Just applied 233823 to current u-boot-ti master. Works fine. OK, thanks. [snip] +* TODO: Replace this ugly hardcoding with proper defines + */ +writel(0x0100, 0x4ae0a310); Again, do please. This should be (*scrm)-auxclk0. The problem is that the omap5_scrm_regs struct (holding the auxclk0 member) has to be defined somewhere in the common OMAP5 headers. Sricharan? Or should I hack around? Add it to the most likely struct in the headers. The entire struct (I call it omap5_scrm_regs in theory, similar to the corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of course I could define only the member that I need, but I guess it is a (responsible) TI job to define hardware descriptors. Or I'm wrong? Please advise. If I have time, I could do it myself - it's some 27 registers, almost identical to the OMAP4, and should go into arch/arm/include/asm/arch-omap5/clocks.h. Whomever uses / needs it should do it. I gave the TRM a quick read and I don't see any conflicts per-se just some reserved areas being named and vice versa. So rename it to omap_scrm_regs and move to asm/omap_common.h. Thanks! I would argue that this is not very appropriate. Those regs that are reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; on the other hand the OMAP5 has some modem clock regs that are reserved on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 and below? We don't need to use ifdefs since there's no conflicts, things are either reserved in one case and used in the other. And we can make sure we don't try and use the omap5 bits on omap4 and vice versa. I don't see scrm in the first omap3 TRM I pulled up, so we don't need to worry there. Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h file and I have already done the same for OMAP5 by analogy. I must admit however that this approach does not correspond to the latest way by which groups of OMAP hardware regs are defined, prcm in particular - a struct in omap_common.h, holding only the required regs, no padding and such garbage, and an init with the physical addresses in a .c file for the particular SoC (prcm-regs.c). But still the Panda board, for example, uses the old way for scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and lazy ;) ). Yes, I'm OK starting off with moving things into omap_common.h as-is and then updating them a bit later ala pcrm-regs.c. I am sorry for the very late response on this. Now then, why not add this register in to omap5_es2_prcm ??. That is how the TRM sees it as well.. Of course, this is cleanup stuff for OMAP4 panda as you pointed out.. Yes, you are right in respect to fluent software integration and consistency with current implementation. My only concern is that from architectural point of view the SCRM, although related to the PRCM, is a separate module (described correspondingly as such in the TRM). If we go this way, the SCRM regs shall have to be referenced via the prcm pointer: (*prcm)-x, and this might be confusing. I'm OK to do it as above, that is, add the SCRM regs (for both OMAP4 and OMAP5) to the prcm_regs declaration in omap_common.h, and the required init to the appropriate omap5_esx_prcm in prcm-regs.c, but would suggest that for improved clarity the SCRM register names, as they now exist in .../arch-omap4/clocks.h
