Hi
On Sun, Sep 29, 2013 at 2:19 AM, Otavio Salvador
ota...@ossystems.com.br wrote:
Hello,
I am trying to add support for watchdog in one board and it is not
working as expected.
I did add the:
#define CONFIG_HW_WATCHDOG
#define CONFIG_IMX_WATCHDOG
into the board config file.
Into the
Hi Fabio,
On Saturday, September 28, 2013 7:22:44 PM, Fabio Estevam wrote:
From: Fabio Estevam fabio.este...@freescale.com
When the GPIO is configured as an output, we should return the value from the
DR
register.
This implements the same fix as in the following kernel commit from FSL
Hi Otavio,
On Saturday, September 28, 2013 9:08:48 PM, Otavio Salvador wrote:
On Sat, Sep 28, 2013 at 1:49 PM, Fabio Estevam feste...@gmail.com wrote:
On Sat, Sep 28, 2013 at 11:17 AM, Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
Dear Otavio Salvador,
On Saturday, September
Hi,
On Sat, 28 Sep 2013 21:19:19 -0300
Otavio Salvador ota...@ossystems.com.br wrote:
I am trying to add support for watchdog in one board and it is not
working as expected.
I did add the:
#define CONFIG_HW_WATCHDOG
#define CONFIG_IMX_WATCHDOG
into the board config file.
Into the
The musb driver defines and uses MUSB_CSR0_H_DIS_PING, however this
bit is reserved on the DM36x. Thus this patch ensures that the
reserved bit is not accesssed.
It has been observed that some USB devices will fail to enumerate
with errors such as 'error in inquiry' without this patch.
See
On 27 September 2013 19:10, Marek Vasut ma...@denx.de wrote:
It would be much nicer if you avoided using this bit in musb_hcd.c instead
of hacking it like this.
Bump? Will we get a V2 here ?
I've posted a v2 on the list, apologies for the slow response.
Andrew Murray
Hi Benoît,
Le Sun, 29 Sep 2013 15:21:52 +0200 (CEST),
Benoît Thébaudeau benoit.thebaud...@advansee.com a écrit :
Why is this required? Is it because there is a different behavior of the PSR
register on one of the i.MXs?
See my commit message here:
On Sun, Sep 29, 2013 at 2:09 PM, Eric Bénard e...@eukrea.com wrote:
Hi Benoît,
Le Sun, 29 Sep 2013 15:21:52 +0200 (CEST),
Benoît Thébaudeau benoit.thebaud...@advansee.com a écrit :
Why is this required? Is it because there is a different behavior of the PSR
register on one of the i.MXs?
On Sun, Sep 29, 2013 at 5:23 AM, Michael Trimarchi
mich...@amarulasolutions.com wrote:
On Sun, Sep 29, 2013 at 2:19 AM, Otavio Salvador
ota...@ossystems.com.br wrote:
I am trying to add support for watchdog in one board and it is not
working as expected.
I did add the:
#define
On Sun, Sep 29, 2013 at 1:57 PM, Anatolij Gustschin ag...@denx.de wrote:
On Sat, 28 Sep 2013 21:19:19 -0300
Otavio Salvador ota...@ossystems.com.br wrote:
I am trying to add support for watchdog in one board and it is not
working as expected.
I did add the:
#define CONFIG_HW_WATCHDOG
Le Sun, 29 Sep 2013 14:48:32 -0300,
Otavio Salvador ota...@ossystems.com.br a écrit :
On Sun, Sep 29, 2013 at 2:09 PM, Eric Bénard e...@eukrea.com wrote:
Hi Benoît,
Le Sun, 29 Sep 2013 15:21:52 +0200 (CEST),
Benoît Thébaudeau benoit.thebaud...@advansee.com a écrit :
Why is this
On Sun, Sep 29, 2013 at 3:19 PM, Eric Bénard e...@eukrea.com wrote:
on which CPU is that ?
Otavio tested it on mx6.
It's strange reading PSR works in the kernel and not in u-boot.
The patch I sent aligns with the kernel behaviour as well:
Hi Fabio,
Le Sun, 29 Sep 2013 15:22:36 -0300,
Fabio Estevam feste...@gmail.com a écrit :
On Sun, Sep 29, 2013 at 3:19 PM, Eric Bénard e...@eukrea.com wrote:
on which CPU is that ?
Otavio tested it on mx6.
It's strange reading PSR works in the kernel and not in u-boot.
The patch I
On Sun, Sep 29, 2013 at 3:26 PM, Eric Bénard e...@eukrea.com wrote:
Hi Fabio,
Le Sun, 29 Sep 2013 15:22:36 -0300,
Fabio Estevam feste...@gmail.com a écrit :
On Sun, Sep 29, 2013 at 3:19 PM, Eric Bénard e...@eukrea.com wrote:
on which CPU is that ?
Otavio tested it on mx6.
It's
Hi Fabio,
On Sunday, September 29, 2013 8:48:46 PM, Fabio Estevam wrote:
On Sun, Sep 29, 2013 at 3:26 PM, Eric Bénard e...@eukrea.com wrote:
Hi Fabio,
Le Sun, 29 Sep 2013 15:22:36 -0300,
Fabio Estevam feste...@gmail.com a écrit :
On Sun, Sep 29, 2013 at 3:19 PM, Eric Bénard
Hi Benoît,
On Sun, Sep 29, 2013 at 3:50 PM, Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
Can you test again without any GPIO patch, but with SION set for this pin in
the
IOMUXC? According to the reference manual, SION not being set in the IOMUXC is
the only reason that would
Hi Fabio,
On Sunday, September 29, 2013 8:58:09 PM, Fabio Estevam wrote:
Hi Benoît,
On Sun, Sep 29, 2013 at 3:50 PM, Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
Can you test again without any GPIO patch, but with SION set for this pin
in the
IOMUXC? According to the
On Sun, Sep 29, 2013 at 4:25 PM, Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
...
Hence, gpio_get_value() should be left unchanged (using PSR in all cases), and
SION should be set for all GPIOs in the i.MX6 pin definition header files.
I just does not follow why this preferred
Hi Otavio,
On Sunday, September 29, 2013 9:42:44 PM, Otavio Salvador wrote:
On Sun, Sep 29, 2013 at 4:25 PM, Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
...
Hence, gpio_get_value() should be left unchanged (using PSR in all cases),
and
SION should be set for all GPIOs in the
On Sun, Sep 29, 2013 at 4:45 PM, Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
On Sunday, September 29, 2013 9:42:44 PM, Otavio Salvador wrote:
On Sun, Sep 29, 2013 at 4:25 PM, Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
...
Hence, gpio_get_value() should be left
On Sun, Sep 29, 2013 at 4:49 PM, Otavio Salvador
ota...@ossystems.com.br wrote:
On Sun, Sep 29, 2013 at 4:45 PM, Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
On Sunday, September 29, 2013 9:42:44 PM, Otavio Salvador wrote:
On Sun, Sep 29, 2013 at 4:25 PM, Benoît Thébaudeau
Dear Andrew Murray,
The musb driver defines and uses MUSB_CSR0_H_DIS_PING, however this
bit is reserved on the DM36x. Thus this patch ensures that the
reserved bit is not accesssed.
It has been observed that some USB devices will fail to enumerate
with errors such as 'error in inquiry'
This changes clock definition of SCIF from CONFIG_SYS_CLK_FREQ to
CONFIG_SH_SCIF_CLK_FREQ, and clock definition of TMU from CONFIG_SYS_CLK_FREQ to
CONFIG_SH_TMU_CLK_FREQ,
Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
CC: Nobuhiro Iwamatsu iwama...@nigauri.org
CC: Albert
This changes clock definition of SCIF from CONFIG_SYS_CLK_FREQ to
CONFIG_SH_SCIF_CLK_FREQ, and clock definition of TMU from CONFIG_SYS_CLK_FREQ to
CONFIG_SH_TMU_CLK_FREQ for boards.
Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
Signed-off-by: Nobuhiro Iwamatsu
The former SH/SCIF driver had calculated baudrate based on CONFIG_SYS_CLK_FREQ.
The newest SH/SCIF needs calculation of the clock for SCIF.
This patch defines clock CONFIG_SH_SCIF_CLK_FREQ for SCIF and changes it to
CONFIG_SH_SCIF_CLK_FREQ from CONFIG_SYS_CLK_FREQ.
Signed-off-by: Nobuhiro
Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
CC: Nobuhiro Iwamatsu iwama...@nigauri.org
CC: Albert Aribaud albert.u.b...@aribaud.net
---
v2: no changes.
re-send as further series.
include/configs/kzm9g.h | 1 +
1 file changed, 1 insertion(+)
diff --git
On Sun, Sep 29, 2013 at 7:24 PM, Otavio Salvador
ota...@ossystems.com.br wrote:
I sent the patch to fix this adding the flag to the GPIO pins.
I tested it and it works fine indeed. The patch is awaiting for
approval as it is a little big. The commitlog is below for reference:
mx6: Add
Hi Tom,
I'd like you to pay attention on this patch
http://patchwork.ozlabs.org/patch/275173/
Regards
Zhao Qiang
-Original Message-
From: Zhao Qiang-B45475
Sent: Monday, September 16, 2013 5:28 PM
To: u-boot@lists.denx.de
Cc: Zhao Qiang-B45475
Subject: [PATCH v3] PCIe:change the
On Sat, Sep 28, 2013 at 11:38 AM, Jagannadha Sutradharudu Teki
jagannadha.sutradharudu-t...@xilinx.com wrote:
python used in buildman doesn't need to be placed in
/usr/bin/python, So use env to ensure that the interpreter
will pick the python from environment.
Usefull with several versions of
Current IFC driver supports till 4K page size NAND flash.
Add support of 8K NAND flash
- Program Spare region size in csor_ext
- Add nand_ecclayout for 4 bit 8 bit ecc
- Defines constants
- Add support of 8K NAND boot.
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
CC: Liu Po
Defines constants required to support 8K page size NAND flash.
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
Changes for v2:Sending as it is
Changes for v3:Sending as it is
include/configs/C29XPCIE.h | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff
nand_ecclayout is present in mtd.h at Linux.
Move this structure to mtd.h to comply with Linux.
Also, increase the ecc placement locations to 640 to suport device having
writesize/oobsize of 8KB/640B. This means that the maximum oobsize has gone
up to 640 bytes and consequently the maximum ecc
0x1D is reserved. So BUCK3DVS1 is started from 0x1e.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
---
include/power/max77686_pmic.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/power/max77686_pmic.h b/include/power/max77686_pmic.h
index c98db1b..16e9016
Hi Antolji,
On 29/09/2013 20:08, Otavio Salvador wrote:
I am booting the board from USB loader. May it be an issue?
No, it shouldn't be an issue. Does the attached patch help?
It does fix the issue! :-)
Can you resend the patch in the usual way to ML for including into
mainline ?
34 matches
Mail list logo
