Re: [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the bus
Hello Pablo,
On Mon, 2010-09-13 at 16:23 +0200, Pablo Bitton wrote:
Hi Philby,
i2c_davinci_wait_bus_not_busy(struct davinci_i2c_dev *dev,
char allow_sleep)
{
unsigned long timeout;
+ static u16 to_cnt;
timeout = jiffies + dev-adapter.timeout;
while (davinci_i2c_read_reg(dev, DAVINCI_I2C_STR_REG)
DAVINCI_I2C_STR_BB) {
- if (time_after(jiffies, timeout)) {
- dev_warn(dev-dev,
-timeout waiting for bus
ready\n);
- return -ETIMEDOUT;
+ if (to_cnt = DAVINCI_I2C_MAX_TRIES) {
+ if (time_after(jiffies, timeout)) {
+ dev_warn(dev-dev,
+ timeout waiting for bus ready
\n);
+ to_cnt++;
+ return -ETIMEDOUT;
+ } else {
+ to_cnt = 0;
+ i2c_recover_bus(dev);
+ i2c_davinci_init(dev);
+ }
}
if (allow_sleep)
schedule_timeout(1);
The resulting loop has the following drawbacks:
1) If to_cnt reaches DAVINCI_I2C_MAX_TRIES+1 (which it currently
can't, see 2) and the i2c bus collapses,
the kernel will be stuck in the loop forever, especially if
allow_sleep is false.
I do not understand how to_cnt can reach DAVINCI_I2C_MAX_TRIES+1. You
seem to be contradicting your own statement, you also say that this
cannot happen!!
2) The to_cnt static var never increments beyond 1.
Precisely.
It's initialized to zero and then kept at zero until the timeout
expires.
When the timeout expires, to_cnt is incremented once, until the
next call to the function, where it will be zeroed again.
How then can your 1st assumption hold good?
3) Do we really want to retry recovering the bus thousands of times,
until the timeout arrives?
It seems to me that if the bus recovery procedure didn't help
after one or two tries, it probably never will.
Once a bus recovery is initiated, we are in the last phase of a recovery
and if that fails the user is left with no other choice but to reset the
target. From the very beginning the idea was to try until timeout.
Wouldn't you have a working system rather than to have to reset the
target?
I also have the following nitpicks:
a) The timeout variable actually holds the finish time.
Well, that's just aesthetic makeover. I could say the timeout is 10
seconds and the finish time is 10 seconds, it sounds the same to me.
b) The i2c_recover_bus function uses dev_err to report a bus recovery
process,
but if all recovery attempts failed and the timeout was reached,
only dev_warn is used to report the timeout.
Agreed. But your patch does not reflect this change.
Other than that the patch is very helpful, thanks a lot.
Below is my suggestion for the wait_bus_not_busy function. My patch
has been tested on a DM6446.
All in all, your patch gives multiple checkpatch errors/warnings (spaces
instead of tabs etc). You have missed out parts of the code present in
the pristine kernel and so will not cleanly apply. To me, there are two
things that are of interest in your patch. First is you got rid of the
static variable definition and the other is usage of dev_err. I fail to
understand your assumption that the kernel will be stuck in the loop
forever, hence I cannot tell how useful this patch really is.
Signed-off-by: Pablo Bitton pablo.bit...@gmail.com
--
diff --git a/drivers/i2c/busses/i2c-davinci.c
b/drivers/i2c/busses/i2c-davinci.c
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -220,16 +261,24 @@ static int i2c_davinci_init(struct
davinci_i2c_dev *dev)
static int i2c_davinci_wait_bus_not_busy(struct davinci_i2c_dev *dev,
char allow_sleep)
{
- unsigned long timeout;
+ unsigned long finish_time;
You have missed out on this line static u16 to_cnt;
+ unsigned long to_cnt = 0;
- timeout = jiffies + dev-adapter.timeout;
+ finish_time = jiffies + dev-adapter.timeout;
+ /* While bus busy */
while (davinci_i2c_read_reg(dev, DAVINCI_I2C_STR_REG)
DAVINCI_I2C_STR_BB) {
Your patch misses out on this line.
if (to_cnt = DAVINCI_I2C_MAX_TRIES) {
Shouldn't you show removing it in the patch?
- if (time_after(jiffies, timeout)) {
+ if (time_after(jiffies, finish_time)) {
dev_warn(dev-dev,
timeout waiting
RE: Driver probe functionality
On Thu, 2010-07-08 at 11:25 +0200, Sean Kelvin Preston wrote:
Hi Jean-Philippe
Thanks for the response.
For platform bus, you can match by id or by name :
for example in the board code you have :
static struct platform_device davinci_nand_device = {
lines removed
And in the driver code :
static struct platform_driver nand_davinci_driver = {
linesremoved
the device and driver name must match if you want the
platform_match function to work.
I have found this code and the observed behaviour I have is that it is doing
a match by name for the TI DM365 EVM board I am using. If I have the old
NAND chip (MT29F16G08FAA) plugged in then I can see platform_match going
through the list and it finds the davinci_nand driver. If I plug my new
NAND chip (MT29F8G08ABABA) in then I can see the same platform_match
occurring but this time it does not find the driver so no match occurs.
I know this particular chip is supported on this EVM as I have managed to
get it working correctly with uBoot but it obviously initialises and defines
things differently to the kernel. So what I do not understand or know is
what decides which drivers should be loaded? Something must be doing a
check based on the fact that I have enabled the driver in the board config
but it is not available for the platform_match to succeed.
You are right, the platform_match() does not succeed based on a simple
string comparison. platform_match() defined in platform.c drivers/base,
does a string comparison of the driver and device name variable. If
there is a name mismatch platform_match() bails out and the probe fails.
Try setting the .name variable in your platform driver and device to
be the same.
Regards,
Philby
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Driver probe functionality
On Thu, 2010-07-08 at 12:37 +0200, Sean Kelvin Preston wrote: Hi Philby You are right, the platform_match() does not succeed based on a simple string comparison. platform_match() defined in platform.c drivers/base, does a string comparison of the driver and device name variable. If there is a name mismatch platform_match() bails out and the probe fails. Try setting the .name variable in your platform driver and device to be the same. The names are the same as I have not changed that code at all. As I was just testing the new NAND I did not change the drivers except to add an additional ID to the drivers/mtd/nand/nand_ids.c file. Otherwise I just replaced the actual chip on the EVM board. This is why I was wondering if there was something else going on when the platform_probe is done or maybe before that which is failing because I need to change or add something elsewhere to identify the new chip. Okay, then how about here, where a check is first done to see if there is a match between the device and driver id if (drv-bus-match !drv-bus-match(dev, drv)) Regards, Philby ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Driver probe functionality
On Thu, 2010-07-08 at 13:28 +0200, Sean Kelvin Preston wrote: Hi The names are the same as I have not changed that code at all. As I was just testing the new NAND I did not change the drivers except to add an additional ID to the drivers/mtd/nand/nand_ids.c file. Otherwise I just replaced the actual chip on the EVM board. This is why I was wondering if there was something else going on when the platform_probe is done or maybe before that which is failing because I need to change or add something elsewhere to identify the new chip. Okay, then how about here, where a check is first done to see if there is a match between the device and driver id if (drv-bus-match !drv-bus-match(dev, drv)) Sorry I am struggling to find this line of code. I am using version 2.6.32-rc2 of the kernel. Where would I look to find this entry? Sorry about that, I was looking at an older kernel version :-) In the function driver_match_device() Regards, Philby ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Driver probe functionality
On Thu, 2010-07-08 at 14:20 +0200, Sean Kelvin Preston wrote: Hi Sorry about that, I was looking at an older kernel version :-) In the function driver_match_device() Thanks for the suggestions and help so far but as I am new to this and I am really not understanding what the problem is. From what I have understood is that the platform_probe and platform_register functions are not loading the driver. You need to identify exactly where the code fails. Like previously mentioned I could think of two such places, can't think of any other. I have not changed anything about the driver except to add the actual chip id to the nand_ids.c file but by looking at the original NAND boot sequence I have observed that this is only used later once the davinci_nand driver is loaded. So when the kernel boots and it needs to determine what hardware is there. How is it doing this? How does it know that a particular driver should be loaded? After a match is found using the id and name variable, the function driver_probe_device() calls really_probe(dev, drv). This is the function that actually calls your driver specific probe function. But you can verify all this by putting printk's in your code. Regards, Philby ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: i2c problem with TVP514x
On 05/04/2010 01:57 PM, Andreas Auer wrote: Hello, currently I'm using the 2.6.32 kernel from the arago project on a customized board similar to the TI EVM with the DM6446 processor. Right now, I have an application running which uses the TVP5146 to capture video from an analog camera. The problem is that I'm getting the message: tvp514x 1-005d: Write: retry ... 1 I already added the fix to recover the i2c bus. So, after the above message the kernel prints: i2c_davinci i2c_davinci.1: initiating i2c bus recovery I get the messages very often! Is it possible that some other i2c devices (AIC33, MSP430, KSZ8893M Ethernet Switch) cause this problem?? Hello, I am curious, does the bus recover after a failure? That is, are you able to capture video after the i2c recovery code does its job? What happens without the i2c bus recovery patch? Regards, Philby ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] i2c: Set SCL pin to gpio functionality before bus recovery
From: Philby John pj...@mvista.com
Date: Wed, 17 Mar 2010 16:20:12 +0530
Subject: [PATCH] Set SCL pin to gpio functionality before bus recovery
Before using the SCL pin, set it to GPIO by conditionally
checking the i2c revision id for peripherals that match 0x05.
Clean up data structures along the way.
Signed-off-by: Philby John pj...@mvista.com
---
arch/arm/mach-davinci/board-dm355-evm.c |1 -
arch/arm/mach-davinci/board-dm644x-evm.c |1 -
arch/arm/mach-davinci/include/mach/i2c.h |3 +--
drivers/i2c/busses/i2c-davinci.c | 19 ---
4 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index aa48e3f..f4cbf54 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -111,7 +111,6 @@ static struct platform_device davinci_nand_device = {
static struct davinci_i2c_platform_data i2c_pdata = {
.bus_freq = 400 /* kHz */,
.bus_delay = 0 /* usec */,
- .sda_pin= 15,
.scl_pin= 14,
};
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index 976e11b..19508e3 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -629,7 +629,6 @@ static struct i2c_board_info __initdata i2c_info[] = {
static struct davinci_i2c_platform_data i2c_pdata = {
.bus_freq = 20 /* kHz */,
.bus_delay = 100 /* usec */,
- .sda_pin= 44,
.scl_pin= 43,
};
diff --git a/arch/arm/mach-davinci/include/mach/i2c.h
b/arch/arm/mach-davinci/include/mach/i2c.h
index 39fdcea..95894ca 100644
--- a/arch/arm/mach-davinci/include/mach/i2c.h
+++ b/arch/arm/mach-davinci/include/mach/i2c.h
@@ -16,8 +16,7 @@
struct davinci_i2c_platform_data {
unsigned intbus_freq; /* standard bus frequency (kHz) */
unsigned intbus_delay; /* post-transaction delay (usec) */
- unsigned intsda_pin;/* GPIO pin ID to use for SDA */
- unsigned intscl_pin;/* GPIO pin ID to use for SCL */
+ unsigned intscl_pin;/* GPIO pin ID to use for SCL */
};
/* for board setup code */
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index 7a28e60..df909e3 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -64,6 +64,7 @@
#define DAVINCI_I2C_IVR_REG0x28
#define DAVINCI_I2C_EMDR_REG 0x2c
#define DAVINCI_I2C_PSC_REG0x30
+#define DAVINCI_I2C_REVID2_REG 0x38
#define DAVINCI_I2C_IVR_AAS0x07
#define DAVINCI_I2C_IVR_SCD0x06
@@ -133,11 +134,21 @@ static inline u16 davinci_i2c_read_reg(struct
davinci_i2c_dev *i2c_dev, int reg)
}
/* Generate a pulse on the i2c clock pin. */
-static void generic_i2c_clock_pulse(unsigned int scl_pin)
+static void generic_i2c_clock_pulse(unsigned int revid, unsigned int scl_pin)
{
u16 i;
+ int ret;
if (scl_pin) {
+ if (revid == 0x05) {
+ ret = gpio_request(scl_pin, SCL Pin\n);
+ if (ret) {
+ pr_warning(gpio request pin %d failed\n,
+ scl_pin);
+ return;
+ }
+ gpio_direction_output(scl_pin, 1);
+ }
/* Send high and low on the SCL line */
for (i = 0; i 9; i++) {
gpio_set_value(scl_pin, 0);
@@ -162,8 +173,10 @@ static void i2c_recover_bus(struct davinci_i2c_dev *dev)
flag |= DAVINCI_I2C_MDR_NACK;
/* write the data into mode register */
davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
- if (pdata)
- generic_i2c_clock_pulse(pdata-scl_pin);
+ if (pdata) {
+ flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_REVID2_REG);
+ generic_i2c_clock_pulse(flag, pdata-scl_pin);
+ }
/* Send STOP */
flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG);
flag |= DAVINCI_I2C_MDR_STP;
--
1.6.3.3.311.g7ec7
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the bus
On 03/17/2010 02:20 AM, Kevin Hilman wrote:
Philby Johnpj...@mvista.com writes:
On 02/08/2010 04:05 PM, Nori, Sekhar wrote:
Hi Philby,
On Fri, Feb 05, 2010 at 19:23:43, Philby John wrote:
Hello Sekhar,
[...]
+/* Generate a pulse on the i2c clock pin. */
+static void generic_i2c_clock_pulse(unsigned int scl_pin)
+{
+ u16 i;
+
+ if (scl_pin) {
+ /* Send high and low on the SCL line */
+ for (i = 0; i 9; i++) {
+ gpio_set_value(scl_pin, 0);
+ udelay(20);
+ gpio_set_value(scl_pin, 1);
+ udelay(20);
+ }
Before using the pins as GPIO, you would have to set the
functionality of these pins as GPIO. You had this code in
previous incarnations of this patch - not sure why it is
dropped now.
I now think that the previous versions were incorrect since
davinci_cfg_reg() does not set the scl or sda pins for gpio
functionality. Instead they set them as scl or sda which is not what
we want at the time of pulsing. The previous versions used
gpio_set_value() in disable_i2c_pins() and then called
davinci_cfg_reg(). After which it called pulse_i2c_clock().
Please correct me if my interpretation of the code is incorrect.
Can we get some resolution here?
I have a queue of davinci i2c patches waiting to go upstream, and I'd
like to get them in for 2.6.35.
The current i2c series is in the 'davinci-i2c' branch of davinci git.
To quote Sekhar, ...Right. It is only an enhancement (and only good
to have at that). This should not stop the current patch from getting
in. So this patch is good to make it to 2.6.35
Please submit an updated version so we can get this stuff upstream.
Right, the enhancement has now been sent.
Regards,
Philby
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the bus
On 03/17/2010 06:48 PM, Nori, Sekhar wrote:
Hi Philby,
On Wed, Mar 17, 2010 at 16:58:44, Philby John wrote:
On 03/17/2010 02:20 AM, Kevin Hilman wrote:
Philby Johnpj...@mvista.com writes:
On 02/08/2010 04:05 PM, Nori, Sekhar wrote:
Hi Philby,
On Fri, Feb 05, 2010 at 19:23:43, Philby John wrote:
Hello Sekhar,
[...]
+/* Generate a pulse on the i2c clock pin. */
+static void generic_i2c_clock_pulse(unsigned int scl_pin)
+{
+ u16 i;
+
+ if (scl_pin) {
+ /* Send high and low on the SCL line */
+ for (i = 0; i9; i++) {
+ gpio_set_value(scl_pin, 0);
+ udelay(20);
+ gpio_set_value(scl_pin, 1);
+ udelay(20);
+ }
Before using the pins as GPIO, you would have to set the
functionality of these pins as GPIO. You had this code in
previous incarnations of this patch - not sure why it is
dropped now.
I now think that the previous versions were incorrect since
davinci_cfg_reg() does not set the scl or sda pins for gpio
functionality. Instead they set them as scl or sda which is not what
we want at the time of pulsing. The previous versions used
gpio_set_value() in disable_i2c_pins() and then called
davinci_cfg_reg(). After which it called pulse_i2c_clock().
Please correct me if my interpretation of the code is incorrect.
Can we get some resolution here?
I have a queue of davinci i2c patches waiting to go upstream, and I'd
like to get them in for 2.6.35.
The current i2c series is in the 'davinci-i2c' branch of davinci git.
To quote Sekhar, ...Right. It is only an enhancement (and only good
to have at that). This should not stop the current patch from getting
in. So this patch is good to make it to 2.6.35
How about the using the free data format method that Brad was
suggesting [1]? That sounds like a much simpler approach than the
GPIO muxing method that this patch is adopting.
I can't seem to agree with your argument. The recovery method adopted
here is part of the standard i2c v3 spec.
I think we should try that method before accepting this approach
as the final one.
It would be wiser allowing this one to go in, since a lot of
reviewing/testing has already been done. Later on we could try the free
data format and hope that this would work. Otherwise, we would still be
without a fix until free data format is done.
Regards,
Philby
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the bus
On 03/05/2010 08:50 PM, Griffis, Brad wrote: Right. I was also hoping to rid of cpu_is_xxx usage. The only other way I could think of is to add pinmux index into i2c platform data struct. What do you think is the best approach? I think passing pinmux index through platform data is fair. Thanks, Sekhar I recently was told of a clever solution for this issue which I documented here: http://wiki.davincidsp.com/index.php/I2C_Tips#External_Slave_Device_Hanging_the_Bus_by_Holding_SDA_Low Basically the solution was to switch to free data format and perform a read. This will cause the I2C to start toggling SCL. I mention it here because I think the free data format mode is available on most processors. (The only device I know that does NOT support free data format is OMAP35x.) You might have a lot less processor-specific code with this approach and it would be applicable to more devices. I don't have any time to write the code/patch myself, but I thought I would at least toss the idea out there. Brad I did go through your document, but what does free data format mean? It would be good to expand the procedure that enables you to move into this mode. If this wouldn't require modfying pinmux settings shouldn't it be part of the core i2c implementation? At present we follow the i2c spec. recovery procedure which you explained in method 1, and as per AN10216-01 I2C Manual is ... •SDA line is then non usable anymore because of the “Slave-Transmitter”mode. •Methods to recover the SDA line are: –Reset the slave device (assuming the device has a Reset pin) –Use a bus recovery sequence to leave the “Slave-Transmitter” mode •Bus recovery sequence is done as following: 1-Send 9 clock pulses on SCL line 2-Ask the master to keep SDA High until the “Slave-Transmitter” releases the SDA line to perform the ACK operation 3-Keeping SDA High during the ACK means that the “Master-Receiver”does not acknowledge the previous byte receive 4-The “Slave-Transmitter” then goes in an idle state 5-The master then sends a STOP command initializing completely the bus Regards, Philby ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the bus
On 02/08/2010 09:33 PM, Nori, Sekhar wrote:
On Mon, Feb 08, 2010 at 20:43:27, Philby John wrote:
Hello Sekhar,
On 02/08/2010 04:05 PM, Nori, Sekhar wrote:
+static void generic_i2c_clock_pulse(unsigned int scl_pin)
+{
+ u16 i;
+
+ if (scl_pin) {
+ /* Send high and low on the SCL line */
+ for (i = 0; i 9; i++) {
+ gpio_set_value(scl_pin, 0);
+ udelay(20);
+ gpio_set_value(scl_pin, 1);
+ udelay(20);
+ }
Before using the pins as GPIO, you would have to set the
functionality of these pins as GPIO. You had this code in
previous incarnations of this patch - not sure why it is
dropped now.
Don't seem to remember having the code in the old versions at least
not in generic_i2c_clock_pulse(). The functions disable_i2c_pins() and
enable_i2c_pins() were discarded as the i2c protocol spec. did not
specify the need. Moreover bus recovered without it. (Tested on DM355
and Dm6446).
Yes, I was referring to the davinci_cfg_reg() calls in
{disable|enable}_i2c_pins() functions. Per the specification
of the DaVinci devices, a pin needs to be muxed as 'GPIO' if
it is to be used as GPIO controlled by GPIO module. It may
have worked on couple of devices but cannot be guaranteed to
work on all DaVinci devices (esp. DA8XX ones).
I think that using davinci_cfg_reg() in generic_i2c_clock_pulse() is the
wrong place to put it. This would require adding davinci_cfg_reg() for
all know davinci platforms. The i2c recovery procedure is correct to
assume that it owns the SCL line at that very moment.
Instead I believe pinmuxing using davinci_cfg_reg(), should be done way
early, just like we do for DM6446 in devices.c -- davinci_init_i2c(),
for all other platforms. What I could do in function
generic_i2c_clock_pulse() is, set SCL to output, and use gpio_request()
by checking REVID2 register value (0x6) for DA8xx and 0x5 for others.
But, the pins should remain as I2C pins till you actually
hit a bus lock-up. That's when you need to convert them to GPIO
pins and start the recovery by pulsing SCL.
It you make them GPIO right at the start, they wont be usable
as I2C pins for normal transfers?
Right. I was also hoping to rid of cpu_is_xxx usage. The only other way
I could think of is to add pinmux index into i2c platform data struct.
What do you think is the best approach?
Regards,
Philby
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the bus
Hello Sekhar,
On 02/08/2010 04:05 PM, Nori, Sekhar wrote:
+static void generic_i2c_clock_pulse(unsigned int scl_pin)
+{
+ u16 i;
+
+ if (scl_pin) {
+ /* Send high and low on the SCL line */
+ for (i = 0; i 9; i++) {
+ gpio_set_value(scl_pin, 0);
+ udelay(20);
+ gpio_set_value(scl_pin, 1);
+ udelay(20);
+ }
Before using the pins as GPIO, you would have to set the
functionality of these pins as GPIO. You had this code in
previous incarnations of this patch - not sure why it is
dropped now.
Don't seem to remember having the code in the old versions at least
not in generic_i2c_clock_pulse(). The functions disable_i2c_pins() and
enable_i2c_pins() were discarded as the i2c protocol spec. did not
specify the need. Moreover bus recovered without it. (Tested on DM355
and Dm6446).
Yes, I was referring to the davinci_cfg_reg() calls in
{disable|enable}_i2c_pins() functions. Per the specification
of the DaVinci devices, a pin needs to be muxed as 'GPIO' if
it is to be used as GPIO controlled by GPIO module. It may
have worked on couple of devices but cannot be guaranteed to
work on all DaVinci devices (esp. DA8XX ones).
I think that using davinci_cfg_reg() in generic_i2c_clock_pulse() is the
wrong place to put it. This would require adding davinci_cfg_reg() for
all know davinci platforms. The i2c recovery procedure is correct to
assume that it owns the SCL line at that very moment.
Instead I believe pinmuxing using davinci_cfg_reg(), should be done way
early, just like we do for DM6446 in devices.c -- davinci_init_i2c(),
for all other platforms. What I could do in function
generic_i2c_clock_pulse() is, set SCL to output, and use gpio_request()
by checking REVID2 register value (0x6) for DA8xx and 0x5 for others.
Let me know what you think.
Regards,
Philby
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the bus
Hello Sekhar,
My apologies for the late mail. Had trouble with our mail server and I
seem to have lost mails. Pulling this thread from the list. Comments
inline...
On Mon, Feb 1, 2010 at 11:27 AM, Nori, Sekhar nsek...@ti.com wrote:
Hi Philby,
On Wed, Jan 27, 2010 at 05:11:33, Kevin Hilman wrote:
From: Philby John pj...@in.mvista.com
Come out of i2c time out condition by following the
bus recovery procedure outlined in the i2c protocol v3 spec.
The kernel must be robust enough to gracefully recover
from i2c bus failure without having to reset the machine.
This is done by first NACKing the slave, pulsing the SCL
line 9 times and then sending the stop command.
This patch has been tested on a DM6446 and DM355
Signed-off-by: Philby John pj...@in.mvista.com
Signed-off-by: Srinivasan, Nageswari nagesw...@ti.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
---
drivers/i2c/busses/i2c-davinci.c | 57
+++--
1 files changed, 53 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c
b/drivers/i2c/busses/i2c-davinci.c
index 35f9daa..5459065 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -36,6 +36,7 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/cpufreq.h
+#include linux/gpio.h
#include mach/hardware.h
#include mach/i2c.h
@@ -43,6 +44,7 @@
/* - global defines --- */
#define DAVINCI_I2C_TIMEOUT (1*HZ)
+#define DAVINCI_I2C_MAX_TRIES 2
#define I2C_DAVINCI_INTR_ALL (DAVINCI_I2C_IMR_AAS | \
DAVINCI_I2C_IMR_SCD | \
DAVINCI_I2C_IMR_ARDY | \
@@ -130,6 +132,44 @@ static inline u16 davinci_i2c_read_reg(struct
davinci_i2c_dev *i2c_dev, int reg)
return __raw_readw(i2c_dev-base + reg);
}
+/* Generate a pulse on the i2c clock pin. */
+static void generic_i2c_clock_pulse(unsigned int scl_pin)
+{
+ u16 i;
+
+ if (scl_pin) {
+ /* Send high and low on the SCL line */
+ for (i = 0; i 9; i++) {
+ gpio_set_value(scl_pin, 0);
+ udelay(20);
+ gpio_set_value(scl_pin, 1);
+ udelay(20);
+ }
Before using the pins as GPIO, you would have to set the
functionality of these pins as GPIO. You had this code in
previous incarnations of this patch - not sure why it is
dropped now.
Don't seem to remember having the code in the old versions at least
not in generic_i2c_clock_pulse(). The functions disable_i2c_pins() and
enable_i2c_pins() were discarded as the i2c protocol spec. did not
specify the need. Moreover bus recovered without it. (Tested on DM355
and Dm6446).
Couple of good to haves:
It will be good to do a gpio_request() before using the pins
as GPIO - though I can see it may have been deemed unnecessary
- the pins are owned by I2C already - even so it may help catch
system configuration errors in later platforms.
Yes, I could use gpio_request() in generic_i2c_clock_pulse().
The I2C peripheral on da8xx itself contains a mode where its
pins could be used as GPIO - so no need for SoC level muxing
and need for the platform data. This seems to be missing from
DM355 though. Thankfully there is a revision id within the I2C
memory map which will help you differentiate the two cases
(revision 0x5 vs 0x6)
I did not entirely follow your above statement. Will usage of
gpio_request() solve the problem for da8xx and DM355 or does it
require a if else condition? A reminder that the present code will
only work for DM6446 and DM355. I do not have a DA8xx to test specific
functionality if it were to be added.
Regards,
Philby
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v3 2/2] i2c: Davinci i2c bus recovery procedure to clear the bus
On Sun, 2010-01-24 at 15:07 +, Ben Dooks wrote:
On Tue, Jan 12, 2010 at 04:47:16PM +0530, Philby John wrote:
From 2565eeda807e49376298ec895a0d9a91a7668417 Mon Sep 17 00:00:00 2001
From: Philby John pj...@in.mvista.com
Date: Mon, 11 Jan 2010 22:39:44 +0530
Subject: [PATCH 2/2] Davinci i2c bus recovery procedure to clear the bus
Come out of i2c time out condition by following the
bus recovery procedure outlined in the i2c protocol v3 spec.
The kernel must be robust enough to gracefully recover
from i2c bus failure without having to reset the machine.
This is done by first NACKing the slave, pulsing the SCL
line 9 times and then sending the stop command.
This patch has been tested on a DM6446 and DM355
Still not sure whether this can be included as a bug-fix or whether
it comes under the new feature category. Also, since it has to get
new data from the platform whose tree it should really go into.
This fix is for the issue that was reported here
http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg13560.html
which IMHO is critical. The issue can be replicated easily and without it the
user is left with no choice but to reset the target.
Yes, it does depend on [PATCH 1/2] for platform dependent data, would
fail otherwise. Could you suggest what may I do in this circumstances?
Regards,
Philby
Signed-off-by: Philby John pj...@in.mvista.com
Signed-off-by: Srinivasan, Nageswari nagesw...@ti.com
---
drivers/i2c/busses/i2c-davinci.c | 57
+++--
1 files changed, 53 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c
b/drivers/i2c/busses/i2c-davinci.c
index 35f9daa..5459065 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -36,6 +36,7 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/cpufreq.h
+#include linux/gpio.h
#include mach/hardware.h
#include mach/i2c.h
@@ -43,6 +44,7 @@
/* - global defines --- */
#define DAVINCI_I2C_TIMEOUT(1*HZ)
+#define DAVINCI_I2C_MAX_TRIES 2
#define I2C_DAVINCI_INTR_ALL(DAVINCI_I2C_IMR_AAS | \
DAVINCI_I2C_IMR_SCD | \
DAVINCI_I2C_IMR_ARDY | \
@@ -130,6 +132,44 @@ static inline u16 davinci_i2c_read_reg(struct
davinci_i2c_dev *i2c_dev, int reg)
return __raw_readw(i2c_dev-base + reg);
}
+/* Generate a pulse on the i2c clock pin. */
+static void generic_i2c_clock_pulse(unsigned int scl_pin)
+{
+ u16 i;
+
+ if (scl_pin) {
+ /* Send high and low on the SCL line */
+ for (i = 0; i 9; i++) {
+ gpio_set_value(scl_pin, 0);
+ udelay(20);
+ gpio_set_value(scl_pin, 1);
+ udelay(20);
+ }
+ }
+}
+
+/* This routine does i2c bus recovery as specified in the
+ * i2c protocol Rev. 03 section 3.16 titled Bus clear
+ */
+static void i2c_recover_bus(struct davinci_i2c_dev *dev)
+{
+ u32 flag = 0;
+ struct davinci_i2c_platform_data *pdata = dev-dev-platform_data;
+
+ dev_err(dev-dev, initiating i2c bus recovery\n);
+ /* Send NACK to the slave */
+ flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG);
+ flag |= DAVINCI_I2C_MDR_NACK;
+ /* write the data into mode register */
+ davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
+ if (pdata)
+ generic_i2c_clock_pulse(pdata-scl_pin);
+ /* Send STOP */
+ flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG);
+ flag |= DAVINCI_I2C_MDR_STP;
+ davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
+}
+
static inline void davinci_i2c_reset_ctrl(struct davinci_i2c_dev *i2c_dev,
int val)
{
@@ -235,14 +275,22 @@ static int i2c_davinci_wait_bus_not_busy(struct
davinci_i2c_dev *dev,
char allow_sleep)
{
unsigned long timeout;
+ static u16 to_cnt;
timeout = jiffies + dev-adapter.timeout;
while (davinci_i2c_read_reg(dev, DAVINCI_I2C_STR_REG)
DAVINCI_I2C_STR_BB) {
- if (time_after(jiffies, timeout)) {
- dev_warn(dev-dev,
-timeout waiting for bus ready\n);
- return -ETIMEDOUT;
+ if (to_cnt = DAVINCI_I2C_MAX_TRIES) {
+ if (time_after(jiffies, timeout)) {
+ dev_warn(dev-dev,
+ timeout waiting for bus ready\n);
+ to_cnt++;
+ return -ETIMEDOUT;
+ } else {
+ to_cnt = 0;
+ i2c_recover_bus(dev
Re: [PATCH v3 1/2] i2c: Add SDA and SCL pin numbers to i2c platform data
Kevin, On Tue, 2010-01-12 at 16:47 +0530, Philby John wrote: From cb3347e45449ff16a332aa164eae24ef6a2432e6 Mon Sep 17 00:00:00 2001 From: Philby John pj...@in.mvista.com Date: Mon, 11 Jan 2010 15:53:31 +0530 Subject: [PATCH 1/2] Add SDA and SCL pin numbers to i2c platform data Patch adds SDA and SCL pin numbers to the i2c platform data structure for Davinci DM355 and DM6446. This at present is used for i2c bus recovery. TODO: Add SDA and SCL pin number information to include all Davinci platforms such as dm355-leopard, dm365, dm646x, da8xx etc. Will this be included in your next pull? My concern was [PATCH v3 2/2] would fail as it depends on data structures in this patch least it be pulled into the i2c git repo by Jean, though chances of that happening are highly unlikely. Would like to follow up with Jean once you include this into your tree. Thanks, Philby ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v3 2/2] i2c: Davinci i2c bus recovery procedure to clear the bus
From 2565eeda807e49376298ec895a0d9a91a7668417 Mon Sep 17 00:00:00 2001
From: Philby John pj...@in.mvista.com
Date: Mon, 11 Jan 2010 22:39:44 +0530
Subject: [PATCH 2/2] Davinci i2c bus recovery procedure to clear the bus
Come out of i2c time out condition by following the
bus recovery procedure outlined in the i2c protocol v3 spec.
The kernel must be robust enough to gracefully recover
from i2c bus failure without having to reset the machine.
This is done by first NACKing the slave, pulsing the SCL
line 9 times and then sending the stop command.
This patch has been tested on a DM6446 and DM355
Signed-off-by: Philby John pj...@in.mvista.com
Signed-off-by: Srinivasan, Nageswari nagesw...@ti.com
---
drivers/i2c/busses/i2c-davinci.c | 57 +++--
1 files changed, 53 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index 35f9daa..5459065 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -36,6 +36,7 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/cpufreq.h
+#include linux/gpio.h
#include mach/hardware.h
#include mach/i2c.h
@@ -43,6 +44,7 @@
/* - global defines --- */
#define DAVINCI_I2C_TIMEOUT(1*HZ)
+#define DAVINCI_I2C_MAX_TRIES 2
#define I2C_DAVINCI_INTR_ALL(DAVINCI_I2C_IMR_AAS | \
DAVINCI_I2C_IMR_SCD | \
DAVINCI_I2C_IMR_ARDY | \
@@ -130,6 +132,44 @@ static inline u16 davinci_i2c_read_reg(struct
davinci_i2c_dev *i2c_dev, int reg)
return __raw_readw(i2c_dev-base + reg);
}
+/* Generate a pulse on the i2c clock pin. */
+static void generic_i2c_clock_pulse(unsigned int scl_pin)
+{
+ u16 i;
+
+ if (scl_pin) {
+ /* Send high and low on the SCL line */
+ for (i = 0; i 9; i++) {
+ gpio_set_value(scl_pin, 0);
+ udelay(20);
+ gpio_set_value(scl_pin, 1);
+ udelay(20);
+ }
+ }
+}
+
+/* This routine does i2c bus recovery as specified in the
+ * i2c protocol Rev. 03 section 3.16 titled Bus clear
+ */
+static void i2c_recover_bus(struct davinci_i2c_dev *dev)
+{
+ u32 flag = 0;
+ struct davinci_i2c_platform_data *pdata = dev-dev-platform_data;
+
+ dev_err(dev-dev, initiating i2c bus recovery\n);
+ /* Send NACK to the slave */
+ flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG);
+ flag |= DAVINCI_I2C_MDR_NACK;
+ /* write the data into mode register */
+ davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
+ if (pdata)
+ generic_i2c_clock_pulse(pdata-scl_pin);
+ /* Send STOP */
+ flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG);
+ flag |= DAVINCI_I2C_MDR_STP;
+ davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
+}
+
static inline void davinci_i2c_reset_ctrl(struct davinci_i2c_dev *i2c_dev,
int val)
{
@@ -235,14 +275,22 @@ static int i2c_davinci_wait_bus_not_busy(struct
davinci_i2c_dev *dev,
char allow_sleep)
{
unsigned long timeout;
+ static u16 to_cnt;
timeout = jiffies + dev-adapter.timeout;
while (davinci_i2c_read_reg(dev, DAVINCI_I2C_STR_REG)
DAVINCI_I2C_STR_BB) {
- if (time_after(jiffies, timeout)) {
- dev_warn(dev-dev,
-timeout waiting for bus ready\n);
- return -ETIMEDOUT;
+ if (to_cnt = DAVINCI_I2C_MAX_TRIES) {
+ if (time_after(jiffies, timeout)) {
+ dev_warn(dev-dev,
+ timeout waiting for bus ready\n);
+ to_cnt++;
+ return -ETIMEDOUT;
+ } else {
+ to_cnt = 0;
+ i2c_recover_bus(dev);
+ i2c_davinci_init(dev);
+ }
}
if (allow_sleep)
schedule_timeout(1);
@@ -324,6 +372,7 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
dev-adapter.timeout);
if (r == 0) {
dev_err(dev-dev, controller timed out\n);
+ i2c_recover_bus(dev);
i2c_davinci_init(dev);
dev-buf_len = 0;
return -ETIMEDOUT;
--
1.6.3.3.MVISTA
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v3 1/2] i2c: Add SDA and SCL pin numbers to i2c platform data
From cb3347e45449ff16a332aa164eae24ef6a2432e6 Mon Sep 17 00:00:00 2001
From: Philby John pj...@in.mvista.com
Date: Mon, 11 Jan 2010 15:53:31 +0530
Subject: [PATCH 1/2] Add SDA and SCL pin numbers to i2c platform data
Patch adds SDA and SCL pin numbers to the i2c platform data
structure for Davinci DM355 and DM6446. This at present is
used for i2c bus recovery.
TODO: Add SDA and SCL pin number information to include all
Davinci platforms such as dm355-leopard, dm365, dm646x, da8xx etc.
Signed-off-by: Philby John pj...@in.mvista.com
---
arch/arm/mach-davinci/board-dm355-evm.c |2 ++
arch/arm/mach-davinci/board-dm644x-evm.c |2 ++
arch/arm/mach-davinci/include/mach/i2c.h |2 ++
3 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index 077ecf4..aa48e3f 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -111,6 +111,8 @@ static struct platform_device davinci_nand_device = {
static struct davinci_i2c_platform_data i2c_pdata = {
.bus_freq = 400 /* kHz */,
.bus_delay = 0 /* usec */,
+ .sda_pin= 15,
+ .scl_pin= 14,
};
static struct snd_platform_data dm355_evm_snd_data;
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index e9612cf..976e11b 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -629,6 +629,8 @@ static struct i2c_board_info __initdata i2c_info[] = {
static struct davinci_i2c_platform_data i2c_pdata = {
.bus_freq = 20 /* kHz */,
.bus_delay = 100 /* usec */,
+ .sda_pin= 44,
+ .scl_pin= 43,
};
static void __init evm_init_i2c(void)
diff --git a/arch/arm/mach-davinci/include/mach/i2c.h
b/arch/arm/mach-davinci/include/mach/i2c.h
index c248e9b..39fdcea 100644
--- a/arch/arm/mach-davinci/include/mach/i2c.h
+++ b/arch/arm/mach-davinci/include/mach/i2c.h
@@ -16,6 +16,8 @@
struct davinci_i2c_platform_data {
unsigned intbus_freq; /* standard bus frequency (kHz) */
unsigned intbus_delay; /* post-transaction delay (usec) */
+ unsigned intsda_pin;/* GPIO pin ID to use for SDA */
+ unsigned intscl_pin;/* GPIO pin ID to use for SCL */
};
/* for board setup code */
--
1.6.3.3.MVISTA
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v1] i2c: Davinci i2c bus recovery procedure to come out of time out conditions
Kevin,
On Tue, 2010-01-05 at 16:31 -0800, Kevin Hilman wrote:
Philby John pj...@in.mvista.com writes:
From 062cfba8b86ccd932eaa498980e703295d86a6cb Mon Sep 17 00:00:00 2001
From: Philby John pj...@in.mvista.com
Date: Mon, 23 Nov 2009 18:08:33 +0530
Subject: [PATCH] Davinci i2c bus recovery procedure to come out of time out
conditions
Get out of i2c time out condition by following the
bus recovery procedure outlined in the i2c protocol v3 spec.
The kernel must be robust enough to gracefully recover
from i2c bus failure without having to reset the machine.
This is done by first NACKing the slave, pulsing the SCL
line 9 times and then sending the stop command.
This patch has been tested on a DM6446 and DM355
How are you testing this? this should also be tested on da8xx by someone.
This patch is redundant but patch v2 did not make it to the list because
of reverse-dns issues. Resending it now. But then again I guess there
will be a v3 because of removal of macro MOD_REG_BIT.
Thank you for your comments.
Regards,
Philby
Signed-off-by: Philby John pj...@in.mvista.com
---
drivers/i2c/busses/i2c-davinci.c | 54
+
1 files changed, 48 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c
b/drivers/i2c/busses/i2c-davinci.c
index 67d88cc..6b4a550 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -35,6 +35,7 @@
#include linux/interrupt.h
#include linux/platform_device.h
#include linux/io.h
+#include linux/gpio.h
#include mach/hardware.h
@@ -43,6 +44,7 @@
/* - global defines --- */
#define DAVINCI_I2C_TIMEOUT(1*HZ)
+#define DAVINCI_I2C_MAX_TRIES 2
#define I2C_DAVINCI_INTR_ALL(DAVINCI_I2C_IMR_AAS | \
DAVINCI_I2C_IMR_SCD | \
DAVINCI_I2C_IMR_ARDY | \
@@ -134,6 +136,38 @@ static inline u16 davinci_i2c_read_reg(struct
davinci_i2c_dev *i2c_dev, int reg)
return __raw_readw(i2c_dev-base + reg);
}
+/* Generate a pulse on the i2c clock pin. */
+static void pulse_i2c_clock(void)
+{
+ gpio_set_value(14, 0);
+ udelay(20);
+ gpio_set_value(14, 1);
+ udelay(20);
+}
+
+/* This routine does i2c bus recovery as specified in the
+ * i2c protocol Rev. 03 section 3.16 titled Bus clear
+ */
+static void i2c_recover_bus(struct davinci_i2c_dev *dev)
+{
+ u16 i;
+ u32 flag = 0;
+
+ dev_err(dev-dev, initiating i2c bus recovery\n);
This looks like a debug leftover. I doubt you want this since
you're calling this function on every xfer.
+ /* Send NACK to the slave */
+ flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG);
+ flag |= DAVINCI_I2C_MDR_NACK;
+ /* write the data into mode register */
+ davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
+ /* Send high and low on the SCL line */
+ for (i = 0; i 9; i++)
+ pulse_i2c_clock();
+ /* Send STOP */
+ flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG);
+ MOD_REG_BIT(flag, DAVINCI_I2C_MDR_STP, 1);
This patch will need some updates as this macro is now gone.
Kevin
+ davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
+}
+
/*
* This functions configures I2C and brings I2C out of reset.
* This function is called during I2C init function. This function
@@ -221,19 +255,26 @@ static int i2c_davinci_wait_bus_not_busy(struct
davinci_i2c_dev *dev,
char allow_sleep)
{
unsigned long timeout;
+ static u16 to_cnt = 0;
timeout = jiffies + dev-adapter.timeout;
while (davinci_i2c_read_reg(dev, DAVINCI_I2C_STR_REG)
- DAVINCI_I2C_STR_BB) {
- if (time_after(jiffies, timeout)) {
- dev_warn(dev-dev,
-timeout waiting for bus ready\n);
- return -ETIMEDOUT;
+DAVINCI_I2C_STR_BB) {
+ if (to_cnt = DAVINCI_I2C_MAX_TRIES) {
+ if (time_after(jiffies, timeout)) {
+ dev_warn(dev-dev,
+ timeout waiting for bus ready\n);
+ to_cnt++;
+ return -ETIMEDOUT;
+ } else {
+ to_cnt = 0;
+ i2c_recover_bus(dev);
+ i2c_davinci_init(dev);
+ }
}
if (allow_sleep)
schedule_timeout(1);
}
-
return 0;
}
@@ -310,6 +351,7 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
dev-adapter.timeout);
if (r == 0) {
dev_err(dev-dev
[PATCH v2] i2c: Davinci i2c bus recovery procedure to clear the bus
From 0372e68cfd14ab37595498234abe39f2f10787d5 Mon Sep 17 00:00:00 2001
From: Philby John pj...@in.mvista.com
Date: Mon, 23 Nov 2009 18:08:33 +0530
Subject: [PATCH] Davinci i2c bus recovery procedure to clear the bus
Come out of i2c time out condition by following the
bus recovery procedure outlined in the i2c protocol v3 spec.
The kernel must be robust enough to gracefully recover
from i2c bus failure without having to reset the machine.
This is done by first NACKing the slave, pulsing the SCL
line 9 times and then sending the stop command.
This patch has been tested on a DM6446 and DM355
Signed-off-by: Philby John pj...@in.mvista.com
Signed-off-by: Srinivasan, Nageswari nagesw...@ti.com
---
TODO: Need to add SDA and SCL pin numbers to the respective
platforms such as dm355-leopard, dm365, dm646x, da8xx etc.
What I have info on is limited to just dm355 and dm6446.
arch/arm/mach-davinci/board-dm355-evm.c |2 +
arch/arm/mach-davinci/board-dm644x-evm.c |2 +
arch/arm/mach-davinci/include/mach/i2c.h |2 +
drivers/i2c/busses/i2c-davinci.c | 60 +++---
4 files changed, 60 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index a9b650d..a20b2de 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -111,6 +111,8 @@ static struct platform_device davinci_nand_device = {
static struct davinci_i2c_platform_data i2c_pdata = {
.bus_freq = 400 /* kHz */,
.bus_delay = 0 /* usec */,
+ .sda_pin= 15,
+ .scl_pin= 14,
};
static struct snd_platform_data dm355_evm_snd_data;
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index fd0398b..b5ce36b 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -628,6 +628,8 @@ static struct i2c_board_info __initdata i2c_info[] = {
static struct davinci_i2c_platform_data i2c_pdata = {
.bus_freq = 20 /* kHz */,
.bus_delay = 100 /* usec */,
+ .sda_pin= 44,
+ .scl_pin= 43,
};
static void __init evm_init_i2c(void)
diff --git a/arch/arm/mach-davinci/include/mach/i2c.h
b/arch/arm/mach-davinci/include/mach/i2c.h
index c248e9b..21be118 100644
--- a/arch/arm/mach-davinci/include/mach/i2c.h
+++ b/arch/arm/mach-davinci/include/mach/i2c.h
@@ -16,6 +16,8 @@
struct davinci_i2c_platform_data {
unsigned intbus_freq; /* standard bus frequency (kHz) */
unsigned intbus_delay; /* post-transaction delay (usec) */
+ unsigned intsda_pin;/* GPIO pin ID to use for SDA */
+ unsigned intscl_pin;/* GPIO pin ID to use for SCL */
};
/* for board setup code */
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index 67d88cc..be18cab 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -35,6 +35,7 @@
#include linux/interrupt.h
#include linux/platform_device.h
#include linux/io.h
+#include linux/gpio.h
#include mach/hardware.h
@@ -43,6 +44,7 @@
/* - global defines --- */
#define DAVINCI_I2C_TIMEOUT(1*HZ)
+#define DAVINCI_I2C_MAX_TRIES 2
#define I2C_DAVINCI_INTR_ALL(DAVINCI_I2C_IMR_AAS | \
DAVINCI_I2C_IMR_SCD | \
DAVINCI_I2C_IMR_ARDY | \
@@ -134,6 +136,44 @@ static inline u16 davinci_i2c_read_reg(struct
davinci_i2c_dev *i2c_dev, int reg)
return __raw_readw(i2c_dev-base + reg);
}
+/* Generate a pulse on the i2c clock pin. */
+static void generic_i2c_clock_pulse(unsigned int scl_pin)
+{
+ u16 i;
+
+ if (scl_pin) {
+ /* Send high and low on the SCL line */
+ for (i = 0; i 9; i++) {
+ gpio_set_value(scl_pin, 0);
+ udelay(20);
+ gpio_set_value(scl_pin, 1);
+ udelay(20);
+ }
+ }
+}
+
+/* This routine does i2c bus recovery as specified in the
+ * i2c protocol Rev. 03 section 3.16 titled Bus clear
+ */
+static void i2c_recover_bus(struct davinci_i2c_dev *dev)
+{
+ u32 flag = 0;
+ struct davinci_i2c_platform_data *pdata = dev-dev-platform_data;
+
+ dev_err(dev-dev, initiating i2c bus recovery\n);
+ /* Send NACK to the slave */
+ flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG);
+ flag |= DAVINCI_I2C_MDR_NACK;
+ /* write the data into mode register */
+ davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
+ if (pdata)
+ generic_i2c_clock_pulse(pdata-scl_pin);
+ /* Send STOP */
+ flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG);
+ MOD_REG_BIT(flag, DAVINCI_I2C_MDR_STP, 1);
+ davinci_i2c_write_reg(dev
Re: how do i enable full speed instead of high speed in the USB
Gopala, On Tue, 2010-01-05 at 10:34 -0500, Gopala Gottumukkala wrote: I want to use Full speed instead of high speed. What needs to be done to work with full speed. You will have better luck getting your question answered on the USB mailing list (linux-...@vger.kernel.org). AFAIK, there are several dependencies that govern detection of speed on hotplug. One is the pull up resistor connected to D+ on the device, that allows the host to tell if its a full speed device. The other IIRC, is the USB clock speed at 480Mb/s for high speed data and full speed data clocked at 12Mb/s Regards, Philby Help appreciated, Thanks - Gopala From: Subbrathnam, Swaminathan [mailto:swami.i...@ti.com] Sent: Tuesday, January 05, 2010 9:41 AM To: Gopala Gottumukkala; davinci-linux-open-source@linux.davincidsp.com Subject: RE: USB storage error Pl. refer to DaVinci Staging GIT kernel hosted at http://arago-project.org/git/people/?p=sneha/linux-davinci-staging.git;a=summary. __ From: Gopala Gottumukkala [mailto:ggott...@cernium.com] Sent: Tuesday, January 05, 2010 8:06 PM To: Subbrathnam, Swaminathan; davinci-linux-open-source@linux.davincidsp.com Subject: RE: USB storage error Which kernel version number is working for you can I know the kernel version number and if any patches please let me know the patches also. - Gopala From: Gopala Gottumukkala Sent: Monday, January 04, 2010 9:13 AM To: 'Subbrathnam, Swaminathan'; davinci-linux-open-source@linux.davincidsp.com Subject: RE: USB storage error Can I know the latest Davinci Git kernel version which is working for you. The kernel version number and where can I down load the latest one. - Gopala From: Subbrathnam, Swaminathan [mailto:swami.i...@ti.com] Sent: Friday, January 01, 2010 8:10 AM To: Gopala Gottumukkala; davinci-linux-open-source@linux.davincidsp.com Subject: RE: USB storage error Gopala, Could you try the latest DaVinci Git. It works for me. regards swami __ From: davinci-linux-open-source-boun...@linux.davincidsp.com [davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Gopala Gottumukkala [ggott...@cernium.com] Sent: Friday, January 01, 2010 1:38 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: USB storage error I have compiled davinci 2.6.30 I mounted the usb manually I ran some sample program which will open, write and delete the file into usb drive. While writing the file into usb drive. It gives the following error and the program dies. Any help would be appreciated on this usb 1-1: reset high speed USB device using musb_hdrc and address 2 usb 1-1: reset high speed USB device using musb_hdrc and address 2 usb 1-1: reset high speed USB device using musb_hdrc and address 2 sd 0:0:0:0: Device offlined - not ready after error recovery sd 0:0:0:0: [sda] Unhandled error code sd 0:0:0:0: [sda] Result: hostbyte=0x05 driverbyte=0x00 end_request: I/O error, dev sda, sector 41584 sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: [sda] Unhandled error code sd 0:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sda, sector 4 sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device sd 0:0:0:0: rejecting I/O to offline device - Gopala NOTICE: The information contained in this email and any document attached hereto is intended only for the named recipient(s). It is the property of Cernium Corporation and shall not be used, disclosed or reproduced without the express written consent of Cernium Corporation. If you are not the intended recipient (or the employee or agent responsible for delivering this message in confidence to the intended recipient(s)), you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this transmittal or its attachments is strictly prohibited. If you have received this transmittal and/or attachments in error, please notify me immediately by reply email or telephone and immediately delete this message and all its attachments. Thank you. NOTICE: The information contained in this email and any document attached hereto is intended only for the named recipient(s). It is the property of Cernium Corporation and shall not be used, disclosed or reproduced without the express written consent of Cernium Corporation. If
Re: [PATCH v2] i2c: Davinci i2c bus recovery procedure to clear the bus
On Wed, 2010-01-06 at 07:16 -0800, Kevin Hilman wrote: Philby John pj...@in.mvista.com writes: From 0372e68cfd14ab37595498234abe39f2f10787d5 Mon Sep 17 00:00:00 2001 From: Philby John pj...@in.mvista.com Date: Mon, 23 Nov 2009 18:08:33 +0530 Subject: [PATCH] Davinci i2c bus recovery procedure to clear the bus Come out of i2c time out condition by following the bus recovery procedure outlined in the i2c protocol v3 spec. The kernel must be robust enough to gracefully recover from i2c bus failure without having to reset the machine. This is done by first NACKing the slave, pulsing the SCL line 9 times and then sending the stop command. This patch has been tested on a DM6446 and DM355 Signed-off-by: Philby John pj...@in.mvista.com Signed-off-by: Srinivasan, Nageswari nagesw...@ti.com For v3, can you break this up into two patches. One for adding the new members to the pdata struct (this will go upstream via davinci git) and another with the i2c driver changes itself (this will go upstream via i2c subsystem.) Ok, will do that then. Regards, Philby ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: USB MAssage Storage drivers
Hello, On Wed, 2009-12-16 at 11:25 -0500, Gopala Gottumukkala wrote: There is no devices file at all in the /proc/bus/usb/ This is strange and I have no idea. I see in your config file that CONFIG_USB_DEVICEFS is enabled that would give you the device interface in proc. And you have all the right CONFIG options enabled needed for proper mass storage detection. Hope you have done as per Sergeri's and Swami's comments. Regards, Philby -Original Message- From: Philby John [mailto:pj...@in.mvista.com] Sent: Wednesday, December 16, 2009 11:20 AM To: Gopala Gottumukkala Cc: davinci-linux-open-source@linux.davincidsp.com; linux-me...@vger.kernel.org Subject: RE: USB MAssage Storage drivers On Wed, 2009-12-16 at 10:53 -0500, Gopala Gottumukkala wrote: (gcc version 3.4.3 (MontaVista 3.4.3-25.0.104.0600975 2006-07-06)) #4 PREEMPT Tue Dec 15 18:10:24 EST 2009 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 CPU: VIVT data cache, VIVT instruction cache Machine: DaVinci DM644x EVM Memory policy: ECC disabled, Data cache writeback DaVinci dm6446 variant 0x0 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 50800 And what good is this above boot log? The log that would be of interest is the one generated the moment you connect a USB Pen drive. A cat /proc/bus/usb/devices would also give you related information on the connected device. Please take a look. Regards, Philby ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: USB MAssage Storage drivers
On Wed, 2009-12-16 at 10:53 -0500, Gopala Gottumukkala wrote: (gcc version 3.4.3 (MontaVista 3.4.3-25.0.104.0600975 2006-07-06)) #4 PREEMPT Tue Dec 15 18:10:24 EST 2009 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 CPU: VIVT data cache, VIVT instruction cache Machine: DaVinci DM644x EVM Memory policy: ECC disabled, Data cache writeback DaVinci dm6446 variant 0x0 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 50800 And what good is this above boot log? The log that would be of interest is the one generated the moment you connect a USB Pen drive. A cat /proc/bus/usb/devices would also give you related information on the connected device. Please take a look. Regards, Philby ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: USB MAssage Storage drivers
On Tue, 2009-12-15 at 18:46 -0500, Gopala Gottumukkala wrote: My target is not recognizing the USB massage storage. I am working the 2.6.32 Davinci kernel Any suggestion and ideas. ahah, this information isn't enough. Your Vendor/Product ID for this device is compared in a lookup a table. If no match is found, your device probably won't be detected as mass storage. You could check in the unusual_devs.h to see if your device is included there, if your device is relatively new you could submit a Vendor/Product ID to the USB dev list for inclusion. Regards, Philby ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: SPI driver
Andrew, On Fri, 2009-12-11 at 10:41 -0500, Andrew Elder wrote: Steve, I'm disappointed in TI's position on this. This page http://focus.ti.com/docs/prod/folders/print/tms320dm6446.html clearly shows SPI as one of the available peripherals, so to my way of thinking TI should be providing an official Linux driver for it. Or at least working towards providing an official SPI driver. If EVMs for a particular processor do not expose all peripherals then the EVMs need to be updated. How does TI internally test that the SPI port works at all ? It has been tested on a DM6467 as it was required by a TI customer to add specific functionality (such as full duplex transmit and receive). Regards, Philby Regards, Andrew Steve Chen wrote: On Fri, 2009-12-11 at 07:45 -0600, Rondeau, Michael wrote: We have been using a bit-banging SPI driver for several years to write to some GPIO expander chips. I now need to read some inputs from the GPIO expander. The driver is not working in read mode and I am debugging it now. But, I was wondering if TI has gotten a TI 6446 hardware SPI driver working. SPI for DM6446 is not officially supported by TI because there is no SPI device on DM644x EVM. Therefore, can not be tested. I would expect the DM6446 SPI to work with some driver modifications. Since you already have the write working, you should be pretty close with read. Regards, Steve ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH/RFC 1/1] recover from davinci i2c time out conditions
Hello David,
On Wed, 2009-07-15 at 10:10 -0700, David Brownell wrote:
On Wednesday 15 July 2009, Philby John wrote:
/*
+ * Configure the i2c data pin as a GPIO input and the i2c clock pin as a
+ * high GPIO output.
+ */
+static void disable_i2c_pins(void)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+ if (cpu_is_davinci_dm355()) {
+ gpio_direction_input(15);
+ gpio_direction_output(14, 0);
+ gpio_set_value(14, 1);
As noted: gpio_direction_output(14, 1) is better.
Now Corrected!
+ davinci_cfg_reg(DM355_I2C_SDA);
+ davinci_cfg_reg(DM355_I2C_SCL);
+ }
+ local_irq_restore(flags);
+}
+
+/* Connect the i2c pins to the i2c controller. */
+static void enable_i2c_pins(void)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+ if (cpu_is_davinci_dm355()) {
+ davinci_cfg_reg(DM355_I2C_SDA);
+ davinci_cfg_reg(DM355_I2C_SCL);
+ }
+ local_irq_restore(flags);
+}
+
+
+/* Generate a pulse on the i2c clock pin. */
+static void pulse_i2c_clock(void)
+{
+ if (cpu_is_davinci_dm355()) {
+ gpio_set_value(14, 0);
+ udelay(20);
+ gpio_set_value(14, 1);
+ udelay(20);
+ }
+}
+
The general problem with how that's done is that the SoC-specific
bits should not be in this file. The mach-davinc/dm355.c file
should hold that configuration; likewise for other SoCs.
Not quite sure what you were expecting here. What I could do is to set
sda_pin and scl_pin in struct davinci_i2c_platform_data, for all davinci
platforms there is, rather than make davinci specific changes to
i2c-gpio.c I would also prefer not to make changes to
board-dm646x-evm.c/board-dm365-evm.c/board-dm355-evm.c etc...
Please let me know what you think.
+ /* Disable i2c */
+ disable_i2c_pins();
+ for (i = 0; i 10; i++)
+ pulse_i2c_clock();
+ /* Re-enable i2c */
+ enable_i2c_pins();
A better description of this is that you're trying to follow
the I2Cv3 instructions about how to *reset* the bus, yes?
This is correct. To be precise, I am following the bus recovery
procedure as outlined in AN10216-01 I2C Manual. Reproducing here as
general information.
•SDA line is then non usable anymore because of the
“Slave-Transmitter”mode.
•Methods to recover the SDA line are:
–Reset the slave device (assuming the device has a Reset pin)
–Use a bus recovery sequence to leave the “Slave-Transmitter” mode
•Bus recovery sequence is done as following:
1-Send 9 clock pulses on SCL line
2-Ask the master to keep SDA High until the “Slave-Transmitter” releases
the SDA line to perform the ACK operation
3-Keeping SDA High during the ACK means that the “Master-Receiver”does
not acknowledge the previous byte receive
4-The “Slave-Transmitter” then goes in an idle state
5-The master then sends a STOP command initializing completely the bus
Thank you for your comments.
Regards,
Philby
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v1] i2c: Davinci i2c bus recovery procedure to come out of time out conditions
From 062cfba8b86ccd932eaa498980e703295d86a6cb Mon Sep 17 00:00:00 2001
From: Philby John pj...@in.mvista.com
Date: Mon, 23 Nov 2009 18:08:33 +0530
Subject: [PATCH] Davinci i2c bus recovery procedure to come out of time out
conditions
Get out of i2c time out condition by following the
bus recovery procedure outlined in the i2c protocol v3 spec.
The kernel must be robust enough to gracefully recover
from i2c bus failure without having to reset the machine.
This is done by first NACKing the slave, pulsing the SCL
line 9 times and then sending the stop command.
This patch has been tested on a DM6446 and DM355
Signed-off-by: Philby John pj...@in.mvista.com
---
drivers/i2c/busses/i2c-davinci.c | 54 +
1 files changed, 48 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index 67d88cc..6b4a550 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -35,6 +35,7 @@
#include linux/interrupt.h
#include linux/platform_device.h
#include linux/io.h
+#include linux/gpio.h
#include mach/hardware.h
@@ -43,6 +44,7 @@
/* - global defines --- */
#define DAVINCI_I2C_TIMEOUT(1*HZ)
+#define DAVINCI_I2C_MAX_TRIES 2
#define I2C_DAVINCI_INTR_ALL(DAVINCI_I2C_IMR_AAS | \
DAVINCI_I2C_IMR_SCD | \
DAVINCI_I2C_IMR_ARDY | \
@@ -134,6 +136,38 @@ static inline u16 davinci_i2c_read_reg(struct
davinci_i2c_dev *i2c_dev, int reg)
return __raw_readw(i2c_dev-base + reg);
}
+/* Generate a pulse on the i2c clock pin. */
+static void pulse_i2c_clock(void)
+{
+ gpio_set_value(14, 0);
+ udelay(20);
+ gpio_set_value(14, 1);
+ udelay(20);
+}
+
+/* This routine does i2c bus recovery as specified in the
+ * i2c protocol Rev. 03 section 3.16 titled Bus clear
+ */
+static void i2c_recover_bus(struct davinci_i2c_dev *dev)
+{
+ u16 i;
+ u32 flag = 0;
+
+ dev_err(dev-dev, initiating i2c bus recovery\n);
+ /* Send NACK to the slave */
+ flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG);
+ flag |= DAVINCI_I2C_MDR_NACK;
+ /* write the data into mode register */
+ davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
+ /* Send high and low on the SCL line */
+ for (i = 0; i 9; i++)
+ pulse_i2c_clock();
+ /* Send STOP */
+ flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG);
+ MOD_REG_BIT(flag, DAVINCI_I2C_MDR_STP, 1);
+ davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
+}
+
/*
* This functions configures I2C and brings I2C out of reset.
* This function is called during I2C init function. This function
@@ -221,19 +255,26 @@ static int i2c_davinci_wait_bus_not_busy(struct
davinci_i2c_dev *dev,
char allow_sleep)
{
unsigned long timeout;
+ static u16 to_cnt = 0;
timeout = jiffies + dev-adapter.timeout;
while (davinci_i2c_read_reg(dev, DAVINCI_I2C_STR_REG)
- DAVINCI_I2C_STR_BB) {
- if (time_after(jiffies, timeout)) {
- dev_warn(dev-dev,
-timeout waiting for bus ready\n);
- return -ETIMEDOUT;
+DAVINCI_I2C_STR_BB) {
+ if (to_cnt = DAVINCI_I2C_MAX_TRIES) {
+ if (time_after(jiffies, timeout)) {
+ dev_warn(dev-dev,
+ timeout waiting for bus ready\n);
+ to_cnt++;
+ return -ETIMEDOUT;
+ } else {
+ to_cnt = 0;
+ i2c_recover_bus(dev);
+ i2c_davinci_init(dev);
+ }
}
if (allow_sleep)
schedule_timeout(1);
}
-
return 0;
}
@@ -310,6 +351,7 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
dev-adapter.timeout);
if (r == 0) {
dev_err(dev-dev, controller timed out\n);
+ i2c_recover_bus(dev);
i2c_davinci_init(dev);
dev-buf_len = 0;
return -ETIMEDOUT;
--
1.6.3.3.MVISTA
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH/RFC 1/1] recover from davinci i2c time out conditions
Hello Sergei,
On Wed, 2009-07-15 at 16:34 +0400, Sergei Shtylyov wrote:
Hello.
Philby John wrote:
From dbe7e824d576636bb15b82a20fd2557fddc9a8f7 Mon Sep 17 00:00:00 2001
From: Philby John pj...@in.mvista.com
Date: Tue, 14 Jul 2009 21:46:47 +0530
Subject: [PATCH] Reset i2c bus to come out of time out conditions
Get out of i2c time out condition by resetting
the i2c bus. The kernel must be robust enough to
gracefully recover from i2c bus failure without having
to reset the machine. This is done by first NACKing the slave
and then resetting the i2c bus after a certain timeout.
Signed-off-by: Philby John pj...@in.mvista.com
diff --git a/drivers/i2c/busses/i2c-davinci.c
b/drivers/i2c/busses/i2c-davinci.c
index 17f2ee7..4ed1a4c 100755
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -35,14 +35,18 @@
#include linux/interrupt.h
#include linux/platform_device.h
#include linux/io.h
+#include linux/gpio.h
#include mach/hardware.h
#include mach/i2c.h
+#include mach/mux.h
+#include mach/cputype.h
/* - global defines --- */
#define DAVINCI_I2C_TIMEOUT(1*HZ)
+#define DAVINCI_I2C_MAX_TRIES 2
#define I2C_DAVINCI_INTR_ALL(DAVINCI_I2C_IMR_AAS | \
DAVINCI_I2C_IMR_SCD | \
DAVINCI_I2C_IMR_ARDY | \
@@ -135,6 +139,50 @@ static inline u16 davinci_i2c_read_reg(struct
davinci_i2c_dev *i2c_dev, int reg)
}
/*
+ * Configure the i2c data pin as a GPIO input and the i2c clock pin as a
+ * high GPIO output.
+ */
+static void disable_i2c_pins(void)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+ if (cpu_is_davinci_dm355()) {
+ gpio_direction_input(15);
+ gpio_direction_output(14, 0);
+ gpio_set_value(14, 1);
Why not just:
gpio_direction_output(14, 1);
+ davinci_cfg_reg(DM355_I2C_SDA);
+ davinci_cfg_reg(DM355_I2C_SCL);
Why enable the pins here?
Corrected.
+ }
+ local_irq_restore(flags);
+}
+
+/* Connect the i2c pins to the i2c controller. */
+static void enable_i2c_pins(void)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+ if (cpu_is_davinci_dm355()) {
+ davinci_cfg_reg(DM355_I2C_SDA);
+ davinci_cfg_reg(DM355_I2C_SCL);
+ }
+ local_irq_restore(flags);
+}
+
+
+/* Generate a pulse on the i2c clock pin. */
+static void pulse_i2c_clock(void)
+{
+ if (cpu_is_davinci_dm355()) {
+ gpio_set_value(14, 0);
+ udelay(20);
+ gpio_set_value(14, 1);
+ udelay(20);
+ }
+}
+
+/*
* This functions configures I2C and brings I2C out of reset.
* This function is called during I2C init function. This function
* also gets called if I2C encounters any errors.
@@ -221,14 +269,36 @@ static int i2c_davinci_wait_bus_not_busy(struct
davinci_i2c_dev *dev,
char allow_sleep)
{
unsigned long timeout;
+ u16 i;
+ static u16 to_cnt = 0;
+ u32 flag = 0;
timeout = jiffies + dev-adapter.timeout;
while (davinci_i2c_read_reg(dev, DAVINCI_I2C_STR_REG)
- DAVINCI_I2C_STR_BB) {
- if (time_after(jiffies, timeout)) {
- dev_warn(dev-dev,
-timeout waiting for bus ready\n);
- return -ETIMEDOUT;
+DAVINCI_I2C_STR_BB) {
+
+ if (to_cnt = DAVINCI_I2C_MAX_TRIES) {
+ if (time_after(jiffies, timeout)) {
+ dev_warn(dev-dev,
+ timeout waiting for bus ready\n);
+ to_cnt++;
+ return -ETIMEDOUT;
+ }
+ } else if (cpu_is_davinci_dm644x() || cpu_is_davinci_dm355()) {
+ to_cnt = 0;
+ dev_err(dev-dev, initiating i2c bus recovery\n);
+ /* Send the NACK to the slave */
+ flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_IMR_REG);
+ flag |= DAVINCI_I2C_MDR_NACK;
Superflous space here...
Corrected!!
+ /* write the data into mode register */
+ davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
How come you're reading from the interrupt mask register but writing
into the mode register which has different layout? :-O
+ /* Disable i2c */
+ disable_i2c_pins();
+ for (i = 0; i 10; i++)
+ pulse_i2c_clock();
+ /* Re-enable i2c */
+ enable_i2c_pins();
+ i2c_davinci_init(dev
Re: [PATCH/RFC 1/1] recover from davinci i2c time out conditions
Hello Troy,
On Wed, 2009-07-15 at 10:15 -0700, Troy Kisky wrote:
Philby John wrote:
From dbe7e824d576636bb15b82a20fd2557fddc9a8f7 Mon Sep 17 00:00:00 2001
From: Philby John pj...@in.mvista.com
Date: Tue, 14 Jul 2009 21:46:47 +0530
Subject: [PATCH] Reset i2c bus to come out of time out conditions
Get out of i2c time out condition by resetting
the i2c bus. The kernel must be robust enough to
gracefully recover from i2c bus failure without having
to reset the machine. This is done by first NACKing the slave
and then resetting the i2c bus after a certain timeout.
Signed-off-by: Philby John pj...@in.mvista.com
---
I personally like the idea behind this patch. But I have
heard others argue against it. But it is not related to the
^C issue others have mentioned. That should not happen in
the GIT kernel.
drivers/i2c/busses/i2c-davinci.c | 98
+++--
1 files changed, 92 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c
b/drivers/i2c/busses/i2c-davinci.c
index 17f2ee7..4ed1a4c 100755
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -35,14 +35,18 @@
#include linux/interrupt.h
#include linux/platform_device.h
#include linux/io.h
+#include linux/gpio.h
#include mach/hardware.h
#include mach/i2c.h
+#include mach/mux.h
+#include mach/cputype.h
/* - global defines --- */
#define DAVINCI_I2C_TIMEOUT(1*HZ)
+#define DAVINCI_I2C_MAX_TRIES 2
#define I2C_DAVINCI_INTR_ALL(DAVINCI_I2C_IMR_AAS | \
DAVINCI_I2C_IMR_SCD | \
DAVINCI_I2C_IMR_ARDY | \
@@ -135,6 +139,50 @@ static inline u16 davinci_i2c_read_reg(struct
davinci_i2c_dev *i2c_dev, int reg)
}
/*
+ * Configure the i2c data pin as a GPIO input and the i2c clock pin as a
+ * high GPIO output.
+ */
+static void disable_i2c_pins(void)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+ if (cpu_is_davinci_dm355()) {
+ gpio_direction_input(15);
+ gpio_direction_output(14, 0);
+ gpio_set_value(14, 1);
+ davinci_cfg_reg(DM355_I2C_SDA);
+ davinci_cfg_reg(DM355_I2C_SCL);
+ }
+ local_irq_restore(flags);
+}
+
+/* Connect the i2c pins to the i2c controller. */
+static void enable_i2c_pins(void)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+ if (cpu_is_davinci_dm355()) {
+ davinci_cfg_reg(DM355_I2C_SDA);
+ davinci_cfg_reg(DM355_I2C_SCL);
+ }
+ local_irq_restore(flags);
+}
+
+
+/* Generate a pulse on the i2c clock pin. */
+static void pulse_i2c_clock(void)
+{
+ if (cpu_is_davinci_dm355()) {
+ gpio_set_value(14, 0);
+ udelay(20);
+ gpio_set_value(14, 1);
+ udelay(20);
+ }
+}
+
+/*
* This functions configures I2C and brings I2C out of reset.
* This function is called during I2C init function. This function
* also gets called if I2C encounters any errors.
@@ -221,14 +269,36 @@ static int i2c_davinci_wait_bus_not_busy(struct
davinci_i2c_dev *dev,
char allow_sleep)
{
unsigned long timeout;
+ u16 i;
+ static u16 to_cnt = 0;
+ u32 flag = 0;
timeout = jiffies + dev-adapter.timeout;
while (davinci_i2c_read_reg(dev, DAVINCI_I2C_STR_REG)
- DAVINCI_I2C_STR_BB) {
- if (time_after(jiffies, timeout)) {
- dev_warn(dev-dev,
-timeout waiting for bus ready\n);
- return -ETIMEDOUT;
+DAVINCI_I2C_STR_BB) {
+
+ if (to_cnt = DAVINCI_I2C_MAX_TRIES) {
+ if (time_after(jiffies, timeout)) {
+ dev_warn(dev-dev,
+ timeout waiting for bus ready\n);
+ to_cnt++;
+ return -ETIMEDOUT;
+ }
+ } else if (cpu_is_davinci_dm644x() || cpu_is_davinci_dm355()) {
I would not initiate recovery until a timeout occurs.
This can be a multi master bus, so a busy condition
may be valid. Then, after multiple timeouts and recovery attempts,
return -ETIMEDOUT
Yes, I agree. I wait for a maximum of 2 tries when a timeout occurs
before initiating bus recovery.
Regards,
Philby
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 0/2] davinci i2c fixes for 2.6.31
Hello Murali, On Thu, 2009-07-16 at 16:22 -0500, Karicheri, Muralidharan wrote: Philby, I tried running this patch against 2.6.31.rc2 (davinci kernel tree). But I got a crash as I run the application which is given below In my case, time out happens when I kill the capture application using Cntrl-C. After Cnrtl-C, the mt9t031 i2c device couldn't be contacted by the host (during cleanup, i2c commands fails). When the application is run again, I get following outputs.. i2c_davinci i2c_davinci.1: timeout waiting for bus ready i2c_davinci i2c_davinci.1: timeout waiting for bus ready Here are the complete log application running and pressed Cntrl-C time:105frame:33 time:105frame:34vpfe-capture vpfe-capture: stream off failed in subdev Running it again . r...@158.218.100.186:/opt/git# ./fbdev_loopback -i2 -d0 I have now verified the code on a DM6446 and DM355, with the ./fbdev_loopback test. I had to first do a #./i2cset -y 0 0x50 0x00 0x w to kill the bus and then run the ./fbdev_loopback test to recreate the issue. Recovery seems to happen with the new patch. Could you try this out at your end, with the new patch? Thanks and regards, Philby ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: question on UART BOOT
Hello, On Tue, 2009-10-27 at 14:31 -0700, Naresh Kansara wrote: Hi, I have a custom designed board with DaVinci. I have downloaded the latest software from SorceForge. My hyper terminal operate at 115200,8N1. I am using CCS JTAG to poke inside ARM code. On PC Host CMD window, I issue the following command Slh_DM644x –load2IRAM slt_DM644x.bin Resulting display on CMD window Waiting for the DM644x... BOOTME commmand received. Returning ACK and header... ACK command sent. Waiting for BEGIN command... Target: BEGIN BEGIN commmand received. Sending CRC table... 100% [ ] CRC table sent Waiting for DONE... DONE received. Sending the UBL... 100% [ ] UBL sent DONE received. UBL was accepted. UBL transmitted successfully. Operation completed successfully. After that I connect the HyperTerminal . On HyperTerminal I get BOOTUBLStarting UART Boot.. From what I gather from your description, you are using the UART Boot Process to load RBL and UBL. And that both loads successfully. Once UBL starts executing it will send a BOOTPSP to the host and then waits for a command from the host such as the default command that beings to download and run an application(eg: Uboot). Once the application(eg: Uboot) has been loaded by UBL it then jumps to the applications entry point. Finally you would see the Uboot prompt. All this should be handled by the host application that you run from hypertermial, in your case Slh_DM644x. Maybe Slh_DM644x must have an option that enables it to send a Uboot header and image to UBL? Or perhaps there is an application that does all this in one shot. Or perhaps someone in TI could point you to right host application to use. You could also refer to Basic Application Loading Over Serial Interface for the DaVinci TMS320DM644x (SPRAAI0) Regards, Philby ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: KGDB with Ethernet support
On Wed, 2009-10-28 at 07:07 +0200, Michael Hallak-Stamler wrote: I have been looking for a Davinci Linux kernel with KGDB. I downloaded and successfully built 2.6.31 that has this support but only provides serial communication. I know that the Montavista kernel has Ethernet communication support. I tried to look at patches but it is not clear to me exactly which patches for which kernel version. Can anyone help me out with this? Try integrating the NetPoll specific patches from here http://www.kernel.org/pub/linux/kernel/people/jwessel/branches/ You could use the kgdb_2.6.30.tar.gz for example and use 0010-NET_POLL-Pass-skb-via-NET_POLL-rx-routine.patch and 0011-kgdb-Implement-kgdb-over-ethernet-with-NET_POLL.patch. AFAIK 2.6.31 already has NET_POLL_CONTROLLER implemented, so you needn't have to change anything in davinci_emac.c You could also get more help from here kgdb-bugrep...@lists.sourceforge.net Regards, Philby ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH/RFC 1/1] recover from davinci i2c time out conditions
Hello Craig, Good to know. With out any modifications on a DM6443? Regards, Philby On Fri, 2009-09-18 at 23:12 -0600, Craig Matsuura wrote: The patch submitted appears specific to the dm355. The changes are very similar to the 2.6.10 kernel from mv. If the correct gpio's and pinmux are disabled/enabled it should work for the dm644x. I took the patch from Philby and tried it on our dm6443 platform (on a 2.6.28 kernel) and it appears to work for the problem we have when the i2c appears to lock up. Craig On Wednesday 22 July 2009 5:14:35 am Philby John wrote: On Wed, 2009-07-22 at 04:03 -0700, Nitin Mahajan wrote: Hello, - Original Message From: Philby John pj...@in.mvista.com To: linux-...@vger.kernel.org Cc: kh...@linux-fr.org; davinci-linux-open-source@linux.davincidsp.com Sent: Wednesday, July 15, 2009 13:04:27 Subject: [PATCH/RFC 1/1] recover from davinci i2c time out conditions From dbe7e824d576636bb15b82a20fd2557fddc9a8f7 Mon Sep 17 00:00:00 2001 From: Philby John Date: Tue, 14 Jul 2009 21:46:47 +0530 Subject: [PATCH] Reset i2c bus to come out of time out conditions Get out of i2c time out condition by resetting the i2c bus. The kernel must be robust enough to gracefully recover from i2c bus failure without having to reset the machine. This is done by first NACKing the slave and then resetting the i2c bus after a certain timeout. Signed-off-by: Philby John I tried this on DM6443 based board with 2.6.18 kernel. The result I am posting below. It gives controller time out again and again. dhcppc9 login: i2c_davinci i2c_davinci.1: controller timed out i2c_davinci i2c_davinci.1: initiating i2c bus recovery i2c_davinci i2c_davinci.1: controller timed out i2c_davinci i2c_davinci.1: initiating i2c bus recovery There is something gravely wrong about this patch and I would submit a fix shortly incorporating the review comments. But please be aware that I do not guarantee a definitive time line for a fix cause I have much at hand at the moment. Regards, Philby ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- __ Craig Matsuura - Principal Engineer Control4 11734 South Election Road - Suite 200 Salt Lake City, UT 84020-6432 PH: 801-523-3161 FX: 801-523-3199 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH/RFC 1/1] recover from davinci i2c time out conditions
On Wed, 2009-07-22 at 04:03 -0700, Nitin Mahajan wrote: Hello, - Original Message From: Philby John pj...@in.mvista.com To: linux-...@vger.kernel.org Cc: kh...@linux-fr.org; davinci-linux-open-source@linux.davincidsp.com Sent: Wednesday, July 15, 2009 13:04:27 Subject: [PATCH/RFC 1/1] recover from davinci i2c time out conditions From dbe7e824d576636bb15b82a20fd2557fddc9a8f7 Mon Sep 17 00:00:00 2001 From: Philby John Date: Tue, 14 Jul 2009 21:46:47 +0530 Subject: [PATCH] Reset i2c bus to come out of time out conditions Get out of i2c time out condition by resetting the i2c bus. The kernel must be robust enough to gracefully recover from i2c bus failure without having to reset the machine. This is done by first NACKing the slave and then resetting the i2c bus after a certain timeout. Signed-off-by: Philby John I tried this on DM6443 based board with 2.6.18 kernel. The result I am posting below. It gives controller time out again and again. dhcppc9 login: i2c_davinci i2c_davinci.1: controller timed out i2c_davinci i2c_davinci.1: initiating i2c bus recovery i2c_davinci i2c_davinci.1: controller timed out i2c_davinci i2c_davinci.1: initiating i2c bus recovery There is something gravely wrong about this patch and I would submit a fix shortly incorporating the review comments. But please be aware that I do not guarantee a definitive time line for a fix cause I have much at hand at the moment. Regards, Philby ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 0/2] davinci i2c fixes for 2.6.31
Hello Murali, I will send a patch out to address this problem. Regards, Philby On Wed, 2009-07-08 at 10:25 -0500, Karicheri, Muralidharan wrote: Hi Kevin, When we do a video loopback with MT9T031, we get i2c timeouts when application is killed using Cntrl C. Is it being addressed in any of the patches? We had the same issue with TI LSP releases (1.20, 2.00, 2.1o etc). The board has to be rebooted to recover from this. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 Phone : 301-515-3736 email: m-kariche...@ti.com -Original Message- From: davinci-linux-open-source-bounces+m- karicheri2=ti@linux.davincidsp.com [mailto:davinci-linux-open-source- bounces+m-karicheri2=ti@linux.davincidsp.com] On Behalf Of Kevin Hilman Sent: Wednesday, July 08, 2009 9:30 AM To: Ben Dooks Cc: davinci-linux-open-source@linux.davincidsp.com; linux- i...@vger.kernel.org Subject: Re: [PATCH 0/2] davinci i2c fixes for 2.6.31 Ben Dooks ben-li...@fluff.org writes: On Mon, Jul 06, 2009 at 03:48:34PM -0700, Kevin Hilman wrote: Here are a couple fixes for the i2c driver on the TI DaVinci family of SoCs. These have been tested for awhile in the DaVinci git repo are needed for 2.6.31. These apply on v2.6.31-rc2. ok, do you have a git branch to pull, or should I apply them from the mailing list You can take from the list. My git branch has a bunch of other non-i2c changes in it as well. Thanks, Kevin David Brownell (1): i2c-davinci: behave with i2cdetect Kevin Hilman (1): i2c-davinci: convert clock usage after clkdev conversion drivers/i2c/busses/i2c-davinci.c | 20 +++- 1 files changed, 15 insertions(+), 5 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ben (b...@fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH/RFC 0/1] recover from davinci i2c time out conditions
This patch address several timeout problems that have been reported like the one below. The kernel must be robust enough to handle such timeouts without having to reboot the system manually. This patch has only been tested on a DM355 hence extensive testing is required on other davinci's as well. Hoping someone will take that up. --- Hi Kevin, When we do a video loopback with MT9T031, we get i2c timeouts when application is killed using Cntrl C. Is it being addressed in any of the patches? We had the same issue with TI LSP releases (1.20, 2.00, 2.1o etc). The board has to be rebooted to recover from this. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 Phone : 301-515-3736 email: m-kariche...@ti.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH/RFC 1/1] recover from davinci i2c time out conditions
From dbe7e824d576636bb15b82a20fd2557fddc9a8f7 Mon Sep 17 00:00:00 2001
From: Philby John pj...@in.mvista.com
Date: Tue, 14 Jul 2009 21:46:47 +0530
Subject: [PATCH] Reset i2c bus to come out of time out conditions
Get out of i2c time out condition by resetting
the i2c bus. The kernel must be robust enough to
gracefully recover from i2c bus failure without having
to reset the machine. This is done by first NACKing the slave
and then resetting the i2c bus after a certain timeout.
Signed-off-by: Philby John pj...@in.mvista.com
---
drivers/i2c/busses/i2c-davinci.c | 98 +++--
1 files changed, 92 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index 17f2ee7..4ed1a4c 100755
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -35,14 +35,18 @@
#include linux/interrupt.h
#include linux/platform_device.h
#include linux/io.h
+#include linux/gpio.h
#include mach/hardware.h
#include mach/i2c.h
+#include mach/mux.h
+#include mach/cputype.h
/* - global defines --- */
#define DAVINCI_I2C_TIMEOUT(1*HZ)
+#define DAVINCI_I2C_MAX_TRIES 2
#define I2C_DAVINCI_INTR_ALL(DAVINCI_I2C_IMR_AAS | \
DAVINCI_I2C_IMR_SCD | \
DAVINCI_I2C_IMR_ARDY | \
@@ -135,6 +139,50 @@ static inline u16 davinci_i2c_read_reg(struct
davinci_i2c_dev *i2c_dev, int reg)
}
/*
+ * Configure the i2c data pin as a GPIO input and the i2c clock pin as a
+ * high GPIO output.
+ */
+static void disable_i2c_pins(void)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+ if (cpu_is_davinci_dm355()) {
+ gpio_direction_input(15);
+ gpio_direction_output(14, 0);
+ gpio_set_value(14, 1);
+ davinci_cfg_reg(DM355_I2C_SDA);
+ davinci_cfg_reg(DM355_I2C_SCL);
+ }
+ local_irq_restore(flags);
+}
+
+/* Connect the i2c pins to the i2c controller. */
+static void enable_i2c_pins(void)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+ if (cpu_is_davinci_dm355()) {
+ davinci_cfg_reg(DM355_I2C_SDA);
+ davinci_cfg_reg(DM355_I2C_SCL);
+ }
+ local_irq_restore(flags);
+}
+
+
+/* Generate a pulse on the i2c clock pin. */
+static void pulse_i2c_clock(void)
+{
+ if (cpu_is_davinci_dm355()) {
+ gpio_set_value(14, 0);
+ udelay(20);
+ gpio_set_value(14, 1);
+ udelay(20);
+ }
+}
+
+/*
* This functions configures I2C and brings I2C out of reset.
* This function is called during I2C init function. This function
* also gets called if I2C encounters any errors.
@@ -221,14 +269,36 @@ static int i2c_davinci_wait_bus_not_busy(struct
davinci_i2c_dev *dev,
char allow_sleep)
{
unsigned long timeout;
+ u16 i;
+ static u16 to_cnt = 0;
+ u32 flag = 0;
timeout = jiffies + dev-adapter.timeout;
while (davinci_i2c_read_reg(dev, DAVINCI_I2C_STR_REG)
- DAVINCI_I2C_STR_BB) {
- if (time_after(jiffies, timeout)) {
- dev_warn(dev-dev,
-timeout waiting for bus ready\n);
- return -ETIMEDOUT;
+DAVINCI_I2C_STR_BB) {
+
+ if (to_cnt = DAVINCI_I2C_MAX_TRIES) {
+ if (time_after(jiffies, timeout)) {
+ dev_warn(dev-dev,
+ timeout waiting for bus ready\n);
+ to_cnt++;
+ return -ETIMEDOUT;
+ }
+ } else if (cpu_is_davinci_dm644x() || cpu_is_davinci_dm355()) {
+ to_cnt = 0;
+ dev_err(dev-dev, initiating i2c bus recovery\n);
+ /* Send the NACK to the slave */
+ flag = davinci_i2c_read_reg(dev, DAVINCI_I2C_IMR_REG);
+ flag |= DAVINCI_I2C_MDR_NACK;
+ /* write the data into mode register */
+ davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
+ /* Disable i2c */
+ disable_i2c_pins();
+ for (i = 0; i 10; i++)
+ pulse_i2c_clock();
+ /* Re-enable i2c */
+ enable_i2c_pins();
+ i2c_davinci_init(dev);
}
if (allow_sleep)
schedule_timeout(1);
@@ -309,7 +379,23 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
r = wait_for_completion_interruptible_timeout(dev-cmd_complete
Re: how can i use spi in dm355?
zuowenping, You need to modify the arch/arm/mach-davinci/davinci_spi_platform.c struct spi_board_info dm6467_spi_board_info[], .modalias = DAVINCI_SPI_EEPROM_NAME, to .modalias = spidev. Also you must enable CONFIG_SPI_SPIDEV. After that the kernel will detect the device as spidev0 and that should get spidev_probe() to work. I think :) Regards, Philby On Tue, 2009-06-23 at 10:00 +0800, zuowenping wrote: I have read the source code ,davinci_spi_board_init() must support board info for the spidev driver ,just like the spi_eeprom example,but i don't know how can i support the board info? i have insmod the module spidev.ko,but i cann't prouduce the device inode /dev/spi*.* ,so it must the spidev_probe() function cann't been callback! 2009-06-23 __ zuowenping __ 发件人： zuowenping 发送时间： 2009-06-22 16:34:45 收件人： davinci-linux-open-source 抄送： chris-meng 主题： how can i use spi in dm355? dear all: I am using mv_pro_4.0.1 in dm355 platform,now i want to use spi0 and spi1 to communication with other devices which is like using i2c open() , read() ,and write() to various device by sub address in userspace. My linux kernel is 2.6.10,I have find the spidev.c and spidev_test.c in linux2.6.30,So i have transplanted the spidev.c as a module in linux kernel 2.6.10,but when i insmod the module,i cann't find the needful device in /dev/ path,so i cann't run spidev_test.c to test spi,I think there may be some errors in dm355 device driver,but i don't know how to modify it? Any help will be appreciated! 2009-06-22 __ zuowenping ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Re: how can i use spi in dm355?
On Tue, 2009-06-23 at 16:14 +0800, zuowenping wrote: thanks Philby very much! I have done according to your words,I cann't see the device node in /dev yet,and i mknod and create node /dev/spidev0, and now i can run my spidev_test.c, # insmod spidev.ko # mknod /dev/spi0 c 153 0 # ./spi_test # spi mode: 3 bits peBUG: scheduling while atomic: spi_test/0x0001/1062 r word: 8 max scaller is schedule+0xec/0x12c peed: 50 Hz (500 KHz) it seem some errors occur! 2009-06-23 It seems to work for me on a DM6467 with Pro5.0. Make sure you pass the correct arguments to spi_test, the default device would be taken as /dev/spidev1.1, so you would need to change that to /dev/spidev0.0, or hardcode char *device = /dev/spidev0.0; My ls shows r...@dm6467_0:~# ls -ls /dev/spidev0.0 0 crw-rw 1 root root 153, 0 Jan 1 00:00 /dev/spidev0.0 Regards, Philby zuowenping __ 发件人： Philby John 发送时间： 2009-06-23 14:51:50 收件人： zuowenping 抄送： davinci-linux-open-source 主题： Re: how can i use spi in dm355? zuowenping, You need to modify the arch/arm/mach-davinci/davinci_spi_platform.c struct spi_board_info dm6467_spi_board_info[], .modalias = DAVINCI_SPI_EEPROM_NAME, to .modalias = spidev. Also you must enable CONFIG_SPI_SPIDEV. After that the kernel will detect the device as spidev0 and that should get spidev_probe() to work. I think :) Regards, Philby On Tue, 2009-06-23 at 10:00 +0800, zuowenping wrote: I have read the source code ,davinci_spi_board_init() must support board info for the spidev driver ,just like the spi_eeprom example,but i don't know how can i support the board info? i have insmod the module spidev.ko,but i cann't prouduce the device inode /dev/spi*.* ,so it must the spidev_probe() function cann't been callback! 2009-06-23 __ zuowenping __ 发件人： zuowenping 发送时间： 2009-06-22 16:34:45 收件人： davinci-linux-open-source 抄送： chris-meng 主题： how can i use spi in dm355? dear all: I am using mv_pro_4.0.1 in dm355 platform,now i want to use spi0 and spi1 to communication with other devices which is like using i2c open() , read() ,and write() to various device by sub address in userspace. My linux kernel is 2.6.10,I have find the spidev.c and spidev_test.c in linux2.6.30,So i have transplanted the spidev.c as a module in linux kernel 2.6.10,but when i insmod the module,i cann't find the needful device in /dev/ path,so i cann't run spidev_test.c to test spi,I think there may be some errors in dm355 device driver,but i don't know how to modify it? Any help will be appreciated! 2009-06-22 __ zuowenping ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Problem with YAFFS2 on LargePage NAND
Hello Zhang, I think you need to change the option in struct nand_davinci_platform_data nand_data, .ecc_mode = NAND_ECC_SOFT, to use s/w ECC. Regards, Philby On Thu, 2009-04-09 at 10:33 +0800, shaofeng zhang wrote: Hi Johns, I had read your message from the email list, and I want to ask you some questions. Which version is your linux kernel? my linux kernel is MVL Pro V4.0(linux 2.6.10), and is yours same with me? How can I ensure my driver use the Software ECC? Should I set some tags or make some changes in the source code? Thank you! Zhang ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Problem with YAFFS2 on LargePage NAND
Hello Zhang, Yes, Pro4.0 does support large page NAND devices, so does Pro5.0 I have got a NAND device with similar configuration as yours (NAND device: Manufacturer ID: 0x20, Chip ID: 0xa1 (ST Micro NAND 128MiB 1,8V 8-bit)) to work on a Pro5.0(2.6.18)/Mobi 5.0(2.6.21) kernel. I haven't tested it on Pro4.0 though. So I would suggest a switch to Pro5.0 or Mobi kernel if its possible. You could also take a look at this fix http://mlblog.osdir.com/file-systems.yaffs/2006-07/msg00012.shtml Regards, Philby On Thu, 2009-03-26 at 10:42 +0800, shaofeng zhang wrote: Hi, Philby, I tried several steps as you suggested before, but the problem was not solved by now. and when I mount the jffs2, there are some errors printed by the kernel. and I want to know if the MV Linux Professional Edition 4.0 does match the LargePage NAND flash or not. You know, when I use the original source code of the MV Linux, the linux kernel scanned the nand flash as all the blocks was bad blocks. and my NAND flash info is the following: TI UBL Version: 1.14, Flash type: NAND Booting PSP Boot Loader PSPBootMode = NAND Starting NAND Copy... Initializing NAND flash... Manufacturer ID = 0x0020 Device ID= 0x00A1 Pages Per Block = 0x0040 Number of Blocks = 0x0400 Bytes Per Page = 0x0800 Valid MagicNum found. NAND Boot success. DONE So I want to find the reasons from this place, maybe there are some mistake in the configration of the MV linux kernel. So, WIll you give me some tips about the NAND configration in the MV linux? Such as the kernel configration, the NAND OOB info, the NAND ECC info, or the process of the BBT building. Thank you. Best Wishes, Zhang 2009/3/23 Philby John pj...@in.mvista.com Zhang, Please keep the mailing list in the loop, someone might have a solution or could use your solution. On Mon, 2009-03-23 at 11:18 +0800, shaofeng zhang wrote: Dear Sir, Sorry, let me introduce myself, my name is Philby. I am sorry to reply your email lately. Because we were rendering our lab's wall these days. And I try to define the YAFFS_IGNORE_TAGS_ECC in the fs/yaffs2/yaffs_ecc.h but there is still the error message: r...@xjtuipcevm:~# df -h FilesystemSize Used Avail Use% Mounted on rootfs 38G 28G 8.0G 78% / /dev/root 38G 28G 8.0G 78% / none 10M 2.5M 7.6M 25% /dev tmpfs 59M 0 59M 0% /tmp none 10M 2.5M 7.6M 25% /dev tmpfs 59M 0 59M 0% /dev/shm /dev/mtdblock4120M 120M 0 100% /mnt/nand And I should tell you that before I modified the /drivers/mtd/nand/nand_bbt.c, there is a mistake when the linux kernel is starting: my board can automaticly boots from the NAND flash througth TI UBL and U-boot 1.2.0. But when starting the linux kernel, there will be the warning messages like this: Starting kernel ... Uncompressing Linux.done. Booting the kernel. (the pre-messages is omitted) NAND device: Manufacturer ID: 0x20, Chip ID: 0xa1 (ST Micro NAND 128MiB 1,8V 8-bit) Scanning device for bad blocks Bad eraseblock 0 at 0x Bad eraseblock 1 at 0x0002 Bad eraseblock 2 at 0x0004 ... Bad eraseblock 1020 at 0x07f8 Bad eraseblock 1021 at 0x07fa Bad eraseblock 1022 at 0x07fc Bad eraseblock 1023 at 0x07fe ... and My Nand Flash is STMICRO's product: NAND01GR3B2B, whose infomation is the following tips: Manufacturer ID = 0x20, Device ID = 0xA1,Pages Per Block = 0x40,Number of Blocks = 0x400,Bytes Per Page = 0x800. I now that the UBL and U-boot can boot from the NAND flash, so I changed the nand_bbt.c(/drivers/mtd/nand/nand_bbt.c) the same as the u-boot/drives/nand/nand_bbt.c,and the kernel mesage shows that there are few bad blocks in the nand flash. What modifications have you done in nand_bbt.c ? After your modifications, yaffs2 reports lesser error? How few are the reported bad blocks? All NAND based flash devices contain some bad blocks
Re: Problem with YAFFS2 on LargePage NAND
Zhang, Please keep the mailing list in the loop, someone might have a solution or could use your solution. On Mon, 2009-03-23 at 11:18 +0800, shaofeng zhang wrote: Dear Sir, Sorry, let me introduce myself, my name is Philby. I am sorry to reply your email lately. Because we were rendering our lab's wall these days. And I try to define the YAFFS_IGNORE_TAGS_ECC in the fs/yaffs2/yaffs_ecc.h but there is still the error message: r...@xjtuipcevm:~# df -h FilesystemSize Used Avail Use% Mounted on rootfs 38G 28G 8.0G 78% / /dev/root 38G 28G 8.0G 78% / none 10M 2.5M 7.6M 25% /dev tmpfs 59M 0 59M 0% /tmp none 10M 2.5M 7.6M 25% /dev tmpfs 59M 0 59M 0% /dev/shm /dev/mtdblock4120M 120M 0 100% /mnt/nand And I should tell you that before I modified the /drivers/mtd/nand/nand_bbt.c, there is a mistake when the linux kernel is starting: my board can automaticly boots from the NAND flash througth TI UBL and U-boot 1.2.0. But when starting the linux kernel, there will be the warning messages like this: Starting kernel ... Uncompressing Linux.done. Booting the kernel. (the pre-messages is omitted) NAND device: Manufacturer ID: 0x20, Chip ID: 0xa1 (ST Micro NAND 128MiB 1,8V 8-bit) Scanning device for bad blocks Bad eraseblock 0 at 0x Bad eraseblock 1 at 0x0002 Bad eraseblock 2 at 0x0004 ... Bad eraseblock 1020 at 0x07f8 Bad eraseblock 1021 at 0x07fa Bad eraseblock 1022 at 0x07fc Bad eraseblock 1023 at 0x07fe ... and My Nand Flash is STMICRO's product: NAND01GR3B2B, whose infomation is the following tips: Manufacturer ID = 0x20, Device ID = 0xA1,Pages Per Block = 0x40,Number of Blocks = 0x400,Bytes Per Page = 0x800. I now that the UBL and U-boot can boot from the NAND flash, so I changed the nand_bbt.c(/drivers/mtd/nand/nand_bbt.c) the same as the u-boot/drives/nand/nand_bbt.c,and the kernel mesage shows that there are few bad blocks in the nand flash. What modifications have you done in nand_bbt.c ? After your modifications, yaffs2 reports lesser error? How few are the reported bad blocks? All NAND based flash devices contain some bad blocks at manufacture, so if its really few then it shouldn't be a cause of worry. So what is your advice when you are facing this problem? I guess there may be some faults in the nand_bbt.c(driveis/mtd/nand)? Is it? I have no idea. But here are some steps you could do to narrow the cause of your problem. 1) Switch to jffs2 to see if the problem goes away. If yes, you could use jffs2 or start debugging the yaffs2 fs code. Turn on debugging using echo all /proc/yaffs before mounting the fs. 2) Switch to using btt on RAM instead of flash and see if the problem exists? You could so this by changing to this-options |= (NAND_USE_DATA_ADJACENT_OOB); in function nand_davinci_probe() - case NAND_ECC_HW_SYNDROME: ie: get rid of the NAND_USE_FLASH_BBT option. 3)Erase mtdblock4 partition from Uboot specifying the offset to the start of your nand fs and the size of your fs (mtdblock4) eg: nand erase 0x240 0x5e0 This will clear all your previous factory marked bbt entries, so use this at your discretion. Regards, Philby 2009/3/19 Philby John pj...@in.mvista.com Zhang, You could try defining YAFFS_IGNORE_TAGS_ECC in fs/yaffs2/yaffs_ecc.h and give it a shot. If this works it would mean, h/w ECC uses up the OOB spare area leaving no space for YAFFS2 to mark bad blocks hence showing 100% usage. Regards, Philby On Wed, 2009-03-18 at 12:55 -0500, Narnakaje, Snehaprabha wrote: Zhang, Which software codebase/release are you using here on DM6446 EVM? The default NAND configuration for DM6446 EVM is to use a small block NAND flash (with page size = 512bytes) and 1-bit HW ECC. If the driver configuration does not match with what the NAND device expects, all blocks of the NAND device can come back as bad blocks. In which case, the corresponding partition will have 100% space used. Thanks Sneha __ From:davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf
RE: Problem with YAFFS2 on LargePage NAND
Zhang, You could try defining YAFFS_IGNORE_TAGS_ECC in fs/yaffs2/yaffs_ecc.h and give it a shot. If this works it would mean, h/w ECC uses up the OOB spare area leaving no space for YAFFS2 to mark bad blocks hence showing 100% usage. Regards, Philby On Wed, 2009-03-18 at 12:55 -0500, Narnakaje, Snehaprabha wrote: Zhang, Which software codebase/release are you using here on DM6446 EVM? The default NAND configuration for DM6446 EVM is to use a small block NAND flash (with page size = 512bytes) and 1-bit HW ECC. If the driver configuration does not match with what the NAND device expects, all blocks of the NAND device can come back as bad blocks. In which case, the corresponding partition will have 100% space used. Thanks Sneha __ From:davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of shaofeng zhang Sent: Tuesday, March 17, 2009 11:22 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: Problem with YAFFS2 on LargePage NAND Hi, All, I am using a 128MB LargePage Nand Flash on my DVEVM board (DM6446), and when I mount the /dev/mtdblock4 throught YAFFS2 fs type, I found that the use% of my nand is 100% as the following: FilesystemSize Used Avail Use% Mounted on rootfs 38G 28G 8.0G 78% / /dev/root 38G 28G 8.0G 78% / none 10M 2.5M 7.6M 25% /dev tmpfs 59M 0 59M 0% /tmp none 10M 2.5M 7.6M 25% /dev tmpfs 59M 0 59M 0% /dev/shm /dev/mtdblock4120M 120M 0 100% /mnt/nand But I first use flash_eraseall to erase the /dev/mtd4 before mounting the /dev/mtdblock4 with YAFFS2 Could anyone tell me some info about the message? Thank you! Best Wishes, Zhang ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: flash_eraseall and mount a mtd ,it show 100% used,why?
zuowenping, What's the flash device you are using, its page size, spare byte usage, bus width etc? Here is what you could try. 1)Try using jffs2 and see if the problem occurs. If not then its a yaffs2 specific issue, which I suspect. 2)Type the following commands in the same order in your UBoot //wipe out bad block markers nand scrub nand erase clean nand erase Please be warned. The following commands will wipe all information including Uboot, boot args location, anything else that's on the flash. If you cannot do that specify offset and size to the above commands for the mtdblock3 partition. 3)If your flash supports 2K page size and the device uses h/w ecc could be that yaffs2 marks all blocks as bad cause it cannot write 32 bytes of extended tags to the spare area, hence showing no useable space left. You could define YAFFS_IGNORE_TAGS_ECC and try mounting yaffs2 again.You could check parameters after boot up by typing cat /proc/yaffs 4)If you are in a mood to debug your problem (assuming the trouble is with yaffs2), switch on debug using echo all /proc/yaffs Regards, Philby On Fri, 2009-02-13 at 15:01 +0800, zuowenping wrote: dear all: I use a new nand flash,and i make 4 partions for bootloader,params,kernel,filesystem when i use a ramdisk for run the kernel success! i operated like: flase_eraseall /dev/mtd3 mount -t yaffs2 /dev/mtdblock3 /mnt dh -h # df -h FilesystemSize Used Available Use% Mounted on /dev/root 9.7M 8.0M 1.2M 87% / tmpfs 966.6M 11.9M954.7M 1% /tmp /dev/root 9.7M 8.0M 1.2M 87% /dev/.static/dev none 10.0M 2.5M 7.5M 25% /dev tmpfs55.8M 0 55.8M 0% /dev/shm none 55.8M 12.0k 55.8M 0% /var/run none966.6M 11.9M954.7M 1% /tmp /dev/mmcblk0p1 966.6M 11.9M954.7M 1% /tmp /dev/mtdblock3 1016.0M 1012.4M 3.6M 100% /mnt //puzzled 100% so i cann't load my rootfs, All files used over 10M size! 2009-02-13 __ zuowenping ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Re: flash_eraseall and mount a mtd ,it show 100% used,why?
Hello, On Fri, 2009-02-13 at 18:29 +0800, zuowenping wrote: dear john: thanks your help very much! My flash is manufactured by Hynix,it have 64 pages a block,and 2k size a page! I cann't use mkfs.jffs2,because my mini ramdisk not support it,I just want to use the mini ramdisk to boot linux. the /proc/yaffs is shows as: # mount -t yaffs2 /dev/mtdblock3 /mnt yaffs: dev is 32505859 name is mtdblock3 yaffs: Attempting MTD mount on 31.3, mtdblock3 block 989 is bad block 3446 is bad block 4029 is bad block 4030 is bad block 4031 is bad block 4032 is bad # cat /proc/yaffs YAFFS built:Feb 2 2008 23:56:53 $Id: yaffs_fs.c,v 1.33 2005/10/27 22:24:04 marty Exp $ $Id: yaffs_guts.c,v 1.22 2005/10/13 02:17:00 charles Exp $ Device 0 filesystem1 startBlock. 0 endBlock... 4095 chunkGroupBits. 3 chunkGroupSize. 8 nErasedBlocks.. 11 You are very low on number of Erasedblocks. Go anywhere lower than 3-5 and yaffs2 will start complaining about yaffs: Block struck out, Block xxx retired errors. This shouldn't be the case when you do a flash_eraseall and mount the partition. See if this fix exists in your code http://www.aleph1.co.uk/lurker/message/20061222.204507.2a8647db.en.html is this the yaffs2 file system error?do i have to modify YAFFS_IGNORE_TAGS_ECC and make uImage ? No harm in trying... Regards, Philby duke zuo da-li tech in hangzhou of china 2009-02-13 __ 发件人： Philby John 发送时间： 2009-02-13 16:52:57 收件人： zuowenping 抄送： davinci-linux-open-source 主题： Re: flash_eraseall and mount a mtd ,it show 100% used,why? zuowenping, What's the flash device you are using, its page size, spare byte usage, bus width etc? Here is what you could try. 1)Try using jffs2 and see if the problem occurs. If not then its a yaffs2 specific issue, which I suspect. 2)Type the following commands in the same order in your UBoot //wipe out bad block markers nand scrub nand erase clean nand erase Please be warned. The following commands will wipe all information including Uboot, boot args location, anything else that's on the flash. If you cannot do that specify offset and size to the above commands for the mtdblock3 partition. 3)If your flash supports 2K page size and the device uses h/w ecc could be that yaffs2 marks all blocks as bad cause it cannot write 32 bytes of extended tags to the spare area, hence showing no useable space left. You could define YAFFS_IGNORE_TAGS_ECC and try mounting yaffs2 again.You could check parameters after boot up by typing cat /proc/yaffs 4)If you are in a mood to debug your problem (assuming the trouble is with yaffs2), switch on debug using echo all /proc/yaffs Regards, Philby On Fri, 2009-02-13 at 15:01 +0800, zuowenping wrote: dear all: I use a new nand flash,and i make 4 partions for bootloader,params,kernel,filesystem when i use a ramdisk for run the kernel success! i operated like: flase_eraseall /dev/mtd3 mount -t yaffs2 /dev/mtdblock3 /mnt dh -h # df -h FilesystemSize Used Available Use% Mounted on /dev/root 9.7M 8.0M 1.2M 87% / tmpfs 966.6M 11.9M954.7M 1% /tmp /dev/root 9.7M 8.0M 1.2M 87% /dev/.static/dev none 10.0M 2.5M 7.5M 25% /dev tmpfs55.8M 0 55.8M 0% /dev/shm none 55.8M 12.0k 55.8M 0% /var/run none966.6M 11.9M954.7M 1% /tmp /dev/mmcblk0p1 966.6M 11.9M954.7M 1% /tmp /dev/mtdblock3 1016.0M 1012.4M 3.6M 100% /mnt //puzzled 100% so i cann't load my rootfs, All files used over 10M size! 2009-02-13 __ zuowenping ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: flash_eraseall and mount a nand flash ,it show 100% used,why?
Hello, On Fri, 2009-02-13 at 19:17 +0800, zuowenping wrote: # cat /proc/yaffs YAFFS built:Feb 2 2008 23:56:53 $Id: yaffs_fs.c,v 1.33 2005/10/27 22:24:04 marty Exp $ $Id: yaffs_guts.c,v 1.22 2005/10/13 02:17:00 charles Exp $ nFreeChunks 768 nPageWrites 0 nPageReads. 0 nBlockErasures. 0 nGCCopies.. 0 garbageCollections. 0 passiveGCs. 0 nRetriedWrites. 0 nRetireBlocks.. 0 eccFixed... 0 eccUnfixed. 0 tagsEccFixed... 0 tagsEccUnfixed. 0 cacheHits.. 0 nDeletedFiles.. 0 nUnlinkedFiles. 0 nBackgroudDeletions 0 useNANDECC. 1 isYaffs2... 1 I am suprised the nFreeChunks is 768,is it mean only 768 pages can be used? Exactly. You could do the math. 768*2048 = 1.5MB So you have approx. 1.5MB of space available for user data. Regards, Philby 2009-02-13 __ zuowenping __ 发件人： zuowenping 发送时间： 2009-02-13 14:57:29 收件人： davinci-linux-open-source 抄送： 主题： flash_eraseall and mount a mtd ,it show 100% used,why? dear all: I use a new nand flash,and i make 4 partions for bootloader,params,kernel,filesystem when i use a ramdisk for run the kernel success! i operated like: flase_eraseall /dev/mtd3 mount -t yaffs2 /dev/mtdblock3 /mnt dh -h # df -h FilesystemSize Used Available Use% Mounted on /dev/root 9.7M 8.0M 1.2M 87% / tmpfs 966.6M 11.9M954.7M 1% /tmp /dev/root 9.7M 8.0M 1.2M 87% /dev/.static/dev none 10.0M 2.5M 7.5M 25% /dev tmpfs55.8M 0 55.8M 0% /dev/shm none 55.8M 12.0k 55.8M 0% /var/run none966.6M 11.9M954.7M 1% /tmp /dev/mmcblk0p1 966.6M 11.9M954.7M 1% /tmp /dev/mtdblock3 1016.0M 1012.4M 3.6M 100% /mnt //puzzled 100% so i cann't load my rootfs, All files used over 10M size! 2009-02-13 __ zuowenping ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Query reg generating an event in DM6467 for every 5 min
On Tue, 2009-01-20 at 23:33 +0900, kirthika varadarajan wrote: I am writing a simple application in which i need to generate an event for every 5 min. I just created a thread inside the thread i need to create an event for every 5 min. I refered to DM6467, there the timers are in kernel and i am not able to link it in my application. Suggest me how to generate events for every 5 min . One way would be to use setitimer() from your application and watch for signals using sigaction(). For eg: you could install a signal handler to watch for expiry after the desired duration for SIGVTALRM. Regards, Philby ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: DM355 EVM NAND reloading with a BDI2000
Excellent, Thank you. Philby On Mon, 2008-12-01 at 11:10 -0600, Jeff Cooper wrote: I've added an article to the Developer Wiki on how to reload a DM355 EVM board using a BDI2000. I've had a request for this information and thought it would be a good idea to make it general knowledge. The link is: http://wiki.davincidsp.com/index.php?title=DM355_DVEVM_NAND_Reloading Jeff ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v5 09/10] ARM: DaVinci: serial mis-behavior on dm646x
Sudhakar,
I could not verify the error message too much work for irq xx when
running tack on a DM6467. Could you please specify the exact command
line parameters/test to run, inorder to reproduce this error.
Thanks and Regards,
Philby
On Fri, 2008-11-14 at 09:57 +0530, Rajashekhara, Sudhakar wrote:
Kevin,
It's true that this behavior is seen across all DM6467 EVMs. If this
fix is not present then the terminal shows up error messages like too
much work for irq xx. After the EVM boots up, you can run the tack
command to test this.
I am not in office today. I can work on the patch on Monday to change the
hardcoded value of 0x8.
Regards, Sudhakar
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Kevin Hilman [EMAIL
PROTECTED]
Sent: Friday, November 14, 2008 6:10 AM
To: Steve Chen
Cc: davinci-linux-open-source@linux.davincidsp.com
Subject: Re: [PATCH v5 09/10] ARM: DaVinci: serial mis-behavior on dm646x
Steve Chen [EMAIL PROTECTED] writes:
Kevin,
I noticed the following code in your patch
+
+ if (cpu_is_davinci_dm646x())
+ davinci_serial_outb(p, UART_DM646X_SCR, 0x8);
You want to use writel. Less than 32bit Writes to the UART controller
locks up the ARM core.
Thanks for the check! With that info, I reworked the patch (see
below) and just make all the serial writes at init time use 32-bit
writes. Then there's a single reset function which works for all
chips, with a special case for dm6467.
Any objectsions?
Kevin
On Thursday 13 November 2008 16:15:36 Kevin Hilman wrote:
Steve Chen [EMAIL PROTECTED] writes:
Kevin,
On Thursday 13 November 2008 13:17:39 Kevin Hilman wrote:
Is this misbehavior specific to the DM6467 EVM or common to any DM6467
board? The patch description could be a bit more descriptive in the
future.
Last month, someone posted on the mailing list about UART2 not working
his
custom board. As it turns out, he needed this same fix for UART2, so
this is
a generic dm6467 issue.
OK, thanks for the clarification. That's what I was expecting. Then
doing this in board init code is definitely wrong.
Also, this patch only fixes UART0. Do we want to consider something more
generic that addresses all three UARTs.
Yes, I'd like to see something more generic.
The 2nd patch I sent is an attempt at doing something more generic,
but it doesn't boot. Since the initial mis-behavior was not well
described in the initial patch, I'm hoping someone (like you :) might
be able to shed some light on why my solution doesn't work.
Kevin
From 45ab9e55aecb73472bd5f682cc68768df172bf11 Mon Sep 17 00:00:00 2001
From: Kevin Hilman [EMAIL PROTECTED]
Date: Thu, 13 Nov 2008 11:10:04 -0800
Subject: [PATCH] DaVinci: DM646x: move serial reset from board code to chip
code
Signed-off-by: Kevin Hilman [EMAIL PROTECTED]
---
arch/arm/mach-davinci/board-dm646x-evm.c | 14 ---
arch/arm/mach-davinci/serial.c | 36 ++---
2 files changed, 17 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index b6a2b22..f311f52 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -117,20 +117,6 @@ static void __init evm_init_i2c(void)
i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info));
}
-#define UART_DM646X_SCR (DAVINCI_UART0_BASE + 0x40)
-/*
- * Internal UARTs need to be initialized for the 8250 autoconfig to work
- * properly. Note that the TX watermark initialization may not be needed
- * once the 8250.c watermark handling code is merged.
- */
-static int __init dm646x_serial_reset(void)
-{
- davinci_writel(0x08, UART_DM646X_SCR);
-
- return 0;
-}
-late_initcall(dm646x_serial_reset);
-
static void board_init(void)
{
davinci_psc_config(DAVINCI_GPSC_ARMDOMAIN, DM646X_LPSC_AEMIF, 1);
diff --git a/arch/arm/mach-davinci/serial.c b/arch/arm/mach-davinci/serial.c
index 1a08ef5..9198978 100644
--- a/arch/arm/mach-davinci/serial.c
+++ b/arch/arm/mach-davinci/serial.c
@@ -37,27 +37,22 @@
#include clock.h
#define UART_DAVINCI_PWREMU 0x0c
+#define UART_DM646X_SCR0x10
+
#define DM355_UART2_BASE (0x01E06000)
-static inline unsigned int davinci_serial_in(struct plat_serial8250_port *up,
- int offset)
+static inline unsigned int serial_read_reg(struct plat_serial8250_port *up,
+ int offset)
{
offset = up-regshift;
- return (unsigned int)__raw_readb(up-membase + offset);
-}
-
-static inline void davinci_serial_outb(struct plat_serial8250_port *p,
- int offset, int value)
-{
- offset =
