[PATCH] i2c: davinci: Fix race when setting up for TX
Move the interrupt enable after the first byte load for TX, as it
was racing with the interrupt handler and corrupting dev-buf_len
for messages 1 byte.
Tested on DM355.
Signed-off-by: Jon Povey jon.po...@racelogic.co.uk
---
The race seems to have been introduced by
869e6692d527983958216f13c3c8e095791909df
This fixes the problem for me, but someone from TI might want to comment
on the validity of starting the transfer before enabling the RDY interrupts.
Any possibility of losing interrupts?
Considered a spinlock but if this reordering is OK then it's neater.
I'm guessing not many people have been sending multi-byte messages..
drivers/i2c/busses/i2c-davinci.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index c87..72df4af 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -347,14 +347,6 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
flag = ~DAVINCI_I2C_MDR_STP;
}
- /* Enable receive or transmit interrupts */
- w = davinci_i2c_read_reg(dev, DAVINCI_I2C_IMR_REG);
- if (msg-flags I2C_M_RD)
- w |= DAVINCI_I2C_IMR_RRDY;
- else
- w |= DAVINCI_I2C_IMR_XRDY;
- davinci_i2c_write_reg(dev, DAVINCI_I2C_IMR_REG, w);
-
dev-terminate = 0;
/* write the data into mode register */
@@ -371,6 +363,14 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
dev-buf_len--;
}
+ /* Enable receive or transmit interrupts */
+ w = davinci_i2c_read_reg(dev, DAVINCI_I2C_IMR_REG);
+ if (msg-flags I2C_M_RD)
+ w |= DAVINCI_I2C_IMR_RRDY;
+ else
+ w |= DAVINCI_I2C_IMR_XRDY;
+ davinci_i2c_write_reg(dev, DAVINCI_I2C_IMR_REG, w);
+
r = wait_for_completion_interruptible_timeout(dev-cmd_complete,
dev-adapter.timeout);
if (r == 0) {
--
1.6.3.3
___
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] DM365EVM: Fix up PHY Clocksource to enable USB Host on DM365EVM
Kevin Hilman wrote: As Sergei pointed out, this is not an adequate changelog. Yes, please ignore this patch as a submission. This type of background info should go after the '---' line so it doesn't make it as part of the git history. What goes here is the what, why and how of the patch itself. History and background info goes after the '---'. Also, considering it was taken from another tree, I'm assuming you are not the original author (unless you completely re-wrote this) so the From: line above should have the original author and the changelog should mention your updates/changes etc Indeed. My original intention of posting was to ensure that the USB Host was enabled in the khilman-git tree, so that I could compare various USB Issues that I have been experiencing from the Arago Tree to the GIT tree. However, I have now been swamped by the USB issues in the Arago tree, and have not yet reviewed the patch comments. Has anyone done any formal testing of the USB Host and CPPI drivers on the DM365 platforms ? Can anyone shed light on the most recent / most reliable / most tested versions of the MUSB/CPPI 3 drivers? Once I have a better understanding of my issues, I can switch back to comparing the two kernel versions and review the comments on this patch. To generate it I had simply diffed the two trees and found those lines as the reason the Host was not being initialised, and so forwarded the patch on thinking it would enable others to use the USB host. But as I am currently finding it unreliable, perhaps that is a symptom of no one having tested the USB on this platform yet. I agree with the comments before, it should reference the Arago original commiter, though to be suitable for the mainline kernel it needs to be reworked. -- Regards Kieran Bingham ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] DM365: fixed second serial port
From: Thomas Koeller thomas.koel...@baslerweb.com
The register base address for the second serial port (UART1) was
wrong.
Signed-off-by: Thomas Koeller thomas.koel...@baslerweb.com
---
arch/arm/mach-davinci/dm365.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index a146849..652f4b6 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1020,6 +1020,8 @@ static struct davinci_timer_info dm365_timer_info = {
.clocksource_id = T0_TOP,
};
+#define DM365_UART1_BASE (IO_PHYS + 0x106000)
+
static struct plat_serial8250_port dm365_serial_platform_data[] = {
{
.mapbase= DAVINCI_UART0_BASE,
@@ -1030,7 +1032,7 @@ static struct plat_serial8250_port
dm365_serial_platform_data[] = {
.regshift = 2,
},
{
- .mapbase= DAVINCI_UART1_BASE,
+ .mapbase= DM365_UART1_BASE,
.irq= IRQ_UARTINT1,
.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
UPF_IOREMAP,
--
1.7.1
___
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] i2c: davinci: Fix race when setting up for TX
Hi, On Tue, Jun 22, 2010 at 13:01:03, Jon Povey wrote: Move the interrupt enable after the first byte load for TX, as it was racing with the interrupt handler and corrupting dev-buf_len for messages 1 byte. Tested on DM355. Signed-off-by: Jon Povey jon.po...@racelogic.co.uk --- The race seems to have been introduced by 869e6692d527983958216f13c3c8e095791909df This fixes the problem for me, but someone from TI might want to comment on the validity of starting the transfer before enabling the RDY interrupts. Any possibility of losing interrupts? This fix can cause interrupts to be missed as there will be a race between writing to DXR and setting of interrupts. I think you can decrement dev-buf_len before writing to DXR register. This should resolve the original race condition which you had encountered. Regards, Sudhakar ___ 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] DM365: fixed second serial port
Hello.
thomas.koel...@baslerweb.com wrote:
From: Thomas Koeller thomas.koel...@baslerweb.com
The register base address for the second serial port (UART1) was
wrong.
Signed-off-by: Thomas Koeller thomas.koel...@baslerweb.com
[...]
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index a146849..652f4b6 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1020,6 +1020,8 @@ static struct davinci_timer_info dm365_timer_info = {
.clocksource_id = T0_TOP,
};
+#define DM365_UART1_BASE (IO_PHYS + 0x106000)
+
Why not declare it in serial.h then?
WBR, Sergei
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Assistance adding new NAND support to kernel
Hi
I am working with a TI DM365 EVM and am attempting to get an alternate NAND
chip working with it as the we are unable to get the exact same chip as is
used on the EVM board. We did a lot of research before selecting the chip
to try find something as close as possible but there are always differences
when you use something newer.
The chip we are trying to use is the Micron MT29F16G08ABABA which has the
following organisation features:
Page Size: 4320 bytes (4096 +224 bytes)
Block Size: 128 pages (512K +28K bytes)
Device Size: 16Gb: 4096 blocks
From our other research we also know that it has the following properties:
ECC: 4bit
Dies: 1
Chip Selects: 1
Chip ID: 0x38
I have tried with the source for the 2.6.32-rc2 (current version shipped
with the EVM SDK) and 2.6.34 kernels by making the modifications below:
So far what I have done is edit drivers/mtd/nand/nand_ids.c to add the
following line to the nand_flash_ids structure:
{NAND 1GiB 3,3V 8-bit,0x38, 0, 1024, 0, LP_OPTIONS},
I also updated arch/arm/configs/davinci_dm365_defconfig to set
NAND_BLOCK_SIZE to be SZ_512K if required.
I can see that the davinci_nand.c driver has code for 4bit HW ECC and
handling 4096 page sizes and did not see anything there that I believed I
needed to add or change. If I boot the EVM with the original NAND chip in
it then I am able to mount and write to the NAND using my new kernel however
if I boot the system using the new NAND chip it does not seem to be
detected. /proc/mtd remains empty and there is no mention of the NAND in
the dmesg output after the system has booted.
Is there somewhere else that I need to change to add support for this chip?
I know it works with the DM365 processor as I have managed to get it working
with uBoot.
Any help would be greatly appreciated.
Regards
Sean
---
Sean Preston
se...@pfk.co.za
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
