Re: [PATCH 6/6] i2c: davinci: bus recovery procedure to clear the bus
?
It seems to me that if the bus recovery procedure didn't help after one
or two tries, it probably never will.
I also have the following nitpicks:
a) The timeout variable actually holds the finish time.
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.
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.
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;
+ 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) {
- if (time_after(jiffies, timeout)) {
+ if (time_after(jiffies, finish_time)) {
dev_warn(dev-dev,
timeout waiting for bus ready\n);
return -ETIMEDOUT;
}
+ else if (to_cnt = DAVINCI_I2C_MAX_TRIES) {
+ dev_warn(dev-dev, bus busy, performing bus recovery\n);
+ ++to_cnt;
+ i2c_recover_bus(dev);
+ i2c_davinci_init(dev);
+ }
if (allow_sleep)
schedule_timeout(1);
}
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2] SPI: DaVinci: Adding SPI driver for DaVinci
This patch adds support for SPI in DaVinci DM6446
(and tries to keep support for DM355/DM365/DM6467 and DA8xx).
Mostly the same as the patch by Sandeep Paulraj.
This has been tested on the DM6446 by defining a spidev device and using a
scope (to check correctness) and a hardware loopback.
This was NOT tested on DM355, DM365 and DM6467 - in fact, it will probably
not work as is because its default mode is CS low-inactive (default mode
of SPI in kernel) - need to set CS_HIGH mode to work as in the previous patch.
Changes from the patch by Sandeep Paulraj:
Bug fixes:
* Additional word written with chip select up after each transfer.
Particulary problematic with NO_CS mode where this word can't be
distiguished from correct words. Problem was in davinci_chip_select.
* setup() for one chip select may interfere with transfer for another
* Small nitpicks (bits that can be changed only on VERSION_2)
Features added:
* Support DM6446
* Support CS_HIGH mode (using SPIDEF register). Note that CS low is default.
Other:
* Less accesses to registers used.
* Once-per-device configuration is done only in probe(), not each transfer.
Uglyness still there:
* VERSION_X definitions for different SPI controllers - added VERSION_3
for the dm6446, which is ugly.
NOTE:
This patch is based on following patches:
SPI: DaVinci: Adding SPI driver for DM3xx/DM6467/DA8xx
The patch adds support for SPI in DaVinci
DM355/DM365/DM6467 and DA8xx.
This has been tested on the DM355, DM365 and DM6467 EVMs using
the EEPROM connected to SPI0
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
DaVinci: DM646x: Adding Support for SPI
The patch does the following
1) Adds a clock for SPI
2) Defines resources specific to DM646x SOC
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
Signed-off-by: Pablo Bitton pablo.bit...@gmail.com
---
arch/arm/mach-davinci/dm644x.c | 50 ++-
arch/arm/mach-davinci/dm646x.c | 53 ++
arch/arm/mach-davinci/include/mach/dm644x.h |3 +
arch/arm/mach-davinci/include/mach/dm646x.h |2 +
arch/arm/mach-davinci/include/mach/spi.h| 46 ++
drivers/spi/Kconfig |7 +
drivers/spi/Makefile|1 +
drivers/spi/davinci_spi.c | 771 +++
drivers/spi/davinci_spi.h | 178 ++
12 files changed, 1149 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-davinci/include/mach/spi.h
create mode 100644 drivers/spi/davinci_spi.c
create mode 100644 drivers/spi/davinci_spi.h
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 55317b1..d395354 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -14,6 +14,7 @@
#include linux/serial_8250.h
#include linux/platform_device.h
#include linux/gpio.h
+#include linux/spi/spi.h
#include asm/mach/map.h
@@ -28,6 +29,7 @@
#include mach/serial.h
#include mach/common.h
#include mach/asp.h
+#include mach/spi.h
#include clock.h
#include mux.h
@@ -306,7 +308,7 @@ struct davinci_clk dm644x_clks[] = {
CLK(palm_bk3710, NULL, ide_clk),
CLK(davinci-asp, NULL, asp_clk),
CLK(davinci_mmc.0, NULL, mmcsd_clk),
- CLK(NULL, spi, spi_clk),
+ CLK(spi_davinci.0, NULL, spi_clk),
CLK(NULL, gpio, gpio_clk),
CLK(NULL, usb, usb_clk),
CLK(NULL, vlynq, vlynq_clk),
@@ -320,6 +322,52 @@ struct davinci_clk dm644x_clks[] = {
CLK(NULL, NULL, NULL),
};
+
+static u64 dm644x_spi_dma_mask = DMA_BIT_MASK(32);
+
+static struct davinci_spi_platform_data dm644x_spi_pdata = {
+ .version= SPI_VERSION_3,
+ .num_chipselect = 2,
+ .clk_internal = 1,
+ .cs_hold= 0,
+ .intr_level = 0,
+ .poll_mode = 1,
+ .c2tdelay = 8,
+ .t2cdelay = 8,
+};
+
+static struct resource dm644x_spi_resources[] = {
+ {
+ .start = 0x01c66800,
+ .end = 0x01c66fff,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = IRQ_SPINT0,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device dm644x_spi_device = {
+ .name = spi_davinci,
+ .id = 0,
+ .dev = {
+ .dma_mask = dm644x_spi_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = dm644x_spi_pdata,
+ },
+ .num_resources = ARRAY_SIZE(dm644x_spi_resources),
+ .resource = dm644x_spi_resources,
+};
+
+void __init dm644x_init_spi(struct spi_board_info *info, unsigned len)
+{
+ spi_register_board_info(info, len);
+
+ platform_device_register(dm644x_spi_device);
+}
+
+
static struct emac_platform_data dm644x_emac_pdata = {
.ctrl_reg_offset= DM644X_EMAC_CNTRL_OFFSET,
.ctrl_mod_reg_offset= DM644X_EMAC_CNTRL_MOD_OFFSET,
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch
Re: Problem regarding DSPLink build
I can recommend building DSPLink using OE/Arago: https://gforge.ti.com/gf/project/arago/mailman/?_forum_action=ForumMessageBrowsethread_id=2096action=ListThreadsmailman_id=39 On Fri, Jul 31, 2009 at 11:43 AM, Vijayabharathi Cvijayabharath...@gmail.com wrote: Hi Iam facing some problem when i tried to built DSPLink in the DM6446 EVM board. I followed the same procedure as mentioned in the below link. but iam facing problem when iam trying to build the Dsplink on arm-linux. http://wiki.davincidsp.com/index.php/How_to_build_an_ARM/DSP_Hello_World_program_on_the_DaVinci_EVM Kindly suggest me any patch to be added? Regards Vijayabharathi C ___ 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 v2.1] davinci_emac: fix kernel oops when changing MAC address while interface is down
Check that network interface is running before changing its MAC address.
Otherwise, rxch is accessed when it's NULL - causing a kernel oops.
Moreover, check that the new MAC address is valid.
Signed-off-by: Pablo Bitton pablo.bit...@gmail.com
Signed-off-by: Chaithrika U S chaithr...@ti.com
Tested-by: Chaithrika U S chaithr...@ti.com
[tested on DM6467 EVM]
---
drivers/net/davinci_emac.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index cf689a0..dddb2b9 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -1821,11 +1821,19 @@ static int emac_dev_setmac_addr(struct net_device
*ndev, void *addr)
struct sockaddr *sa = addr;
DECLARE_MAC_BUF(mac);
+ if (!is_valid_ether_addr(sa-sa_data))
+ return -EINVAL;
+
/* Store mac addr in priv and rx channel and set it in EMAC hw */
memcpy(priv-mac_addr, sa-sa_data, ndev-addr_len);
- memcpy(rxch-mac_addr, sa-sa_data, ndev-addr_len);
memcpy(ndev-dev_addr, sa-sa_data, ndev-addr_len);
- emac_setmac(priv, EMAC_DEF_RX_CH, rxch-mac_addr);
+
+ /* If the interface is down - rxch is NULL. */
+ /* MAC address is configured only after the interface is enabled. */
+ if (netif_running(ndev)) {
+ memcpy(rxch-mac_addr, sa-sa_data, ndev-addr_len);
+ emac_setmac(priv, EMAC_DEF_RX_CH, rxch-mac_addr);
+ }
if (netif_msg_drv(priv))
dev_notice(emac_dev, DaVinci EMAC: emac_dev_setmac_addr %s\n,
--
1.5.4.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 v2.1] davinci_emac: fix kernel oops when changing MAC address while interface is down
Hi,
I've resubmitted this patch since my email client has corrupted
the v2 patch, turning TAB characters into spaces.
Hopefully, this won't happen again.
On Tue, Jul 7, 2009 at 9:10 AM, Pablo Bittonpablo.bit...@gmail.com wrote:
Check that network interface is running before changing its MAC address.
Otherwise, rxch is accessed when it's NULL - causing a kernel oops.
Moreover, check that the new MAC address is valid.
Signed-off-by: Pablo Bitton pablo.bit...@gmail.com
Signed-off-by: Chaithrika U S chaithr...@ti.com
Tested-by: Chaithrika U S chaithr...@ti.com
[tested on DM6467 EVM]
---
drivers/net/davinci_emac.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index cf689a0..dddb2b9 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -1821,11 +1821,19 @@ static int emac_dev_setmac_addr(struct net_device
*ndev, void *addr)
struct sockaddr *sa = addr;
DECLARE_MAC_BUF(mac);
+ if (!is_valid_ether_addr(sa-sa_data))
+ return -EINVAL;
+
/* Store mac addr in priv and rx channel and set it in EMAC hw */
memcpy(priv-mac_addr, sa-sa_data, ndev-addr_len);
- memcpy(rxch-mac_addr, sa-sa_data, ndev-addr_len);
memcpy(ndev-dev_addr, sa-sa_data, ndev-addr_len);
- emac_setmac(priv, EMAC_DEF_RX_CH, rxch-mac_addr);
+
+ /* If the interface is down - rxch is NULL. */
+ /* MAC address is configured only after the interface is enabled. */
+ if (netif_running(ndev)) {
+ memcpy(rxch-mac_addr, sa-sa_data, ndev-addr_len);
+ emac_setmac(priv, EMAC_DEF_RX_CH, rxch-mac_addr);
+ }
if (netif_msg_drv(priv))
dev_notice(emac_dev, DaVinci EMAC: emac_dev_setmac_addr %s\n,
--
1.5.4.3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2] davinci_emac: fix kernel oops when changing MAC address while interface is down
Check that network interface is running before changing its MAC address.
Otherwise, rxch is accessed when it's NULL - causing a kernel oops.
Moreover, check that the new MAC address is valid.
Signed-off-by: Pablo Bitton pablo.bit...@gmail.com
Signed-off-by: Chaithrika U S chaithr...@ti.com
Tested-by: Chaithrika U S chaithr...@ti.com
[tested on DM6467 EVM]
---
drivers/net/davinci_emac.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index cf689a0..dddb2b9 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -1821,11 +1821,19 @@ static int emac_dev_setmac_addr(struct net_device
*ndev, void *addr)
struct sockaddr *sa = addr;
DECLARE_MAC_BUF(mac);
+ if (!is_valid_ether_addr(sa-sa_data))
+ return -EINVAL;
+
/* Store mac addr in priv and rx channel and set it in EMAC hw */
memcpy(priv-mac_addr, sa-sa_data, ndev-addr_len);
- memcpy(rxch-mac_addr, sa-sa_data, ndev-addr_len);
memcpy(ndev-dev_addr, sa-sa_data, ndev-addr_len);
- emac_setmac(priv, EMAC_DEF_RX_CH, rxch-mac_addr);
+
+ /* If the interface is down - rxch is NULL. */
+ /* MAC address is configured only after the interface is enabled. */
+ if (netif_running(ndev)) {
+ memcpy(rxch-mac_addr, sa-sa_data, ndev-addr_len);
+ emac_setmac(priv, EMAC_DEF_RX_CH, rxch-mac_addr);
+ }
if (netif_msg_drv(priv))
dev_notice(emac_dev, DaVinci EMAC: emac_dev_setmac_addr %s\n,
--
1.5.4.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: A small fix to davinci_emac driver
Hello all,
I have attached a small fix for the following problem:
When davinci_emac interface is down, changing MAC address results in
kernel oops, due to NULL pointer dereference.
I apologize for not inlining the patch into the message (since GMail
is the only web client I can use, and it does not allow me to inline
it correctly).
Remarks are welcomed.
Thanks in advance.
On Thu, Jun 25, 2009 at 11:31 AM, Nori, Sekharnsek...@ti.com wrote:
Pablo,
Chaithrika's mails to gmail.com are bouncing, so I am replying
on her behalf.
You are right there is indeed an issue. We looked at other
drivers and found that this is solved by checking for netif_running
to be true before going ahead and setting the mac address. Have a
look at how this is done in tg3.c driver
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=blob;f=drivers/net/tg3.c;h=201be425643a6fb7acb8801718897c9a6431;hb=35265abf67337f57a023ffeae5f4c492e7f8ea24#l6589
Can you please go ahead and submit a fix for this to netdev
mailing list and CC linux-davinci ML?
Thanks,
Sekhar
-Original Message-
From: Pablo Bitton [mailto:pablo.bit...@gmail.com]
Sent: Wednesday, June 24, 2009 7:13 PM
To: Subrahmanya, Chaithrika
Subject: A small fix to davinci_emac driver
Hello,
In drivers/net/davinci_emac.c file, at emac_dev_setmac_addr() function, rxch
is NULL when DaVinci EMAC is down (using ifconfig eth0 down).
So when MAC address is changed using ifconfig eth0 hw ether
00:11:22:33:44:55,
emac_dev_setmac_addr() performs an illegal access to rxch-mac_addr, which
causes a kernel oops.
In order to fix this situation, the attached patch is applied (I've couldn't
inline it correctly into GMail).
Remarks are welcomed.
Thanks in advance.
From ae9480af26eba3302614ea3d92077a80341cd190 Mon Sep 17 00:00:00 2001
From: Pablo Bitton pablo.bit...@gmail.com
Date: Tue, 23 Jun 2009 15:45:43 +0300
Subject: [PATCH] davinci_emac: fix kernel oops when changing MAC address while
interface is down
rxch == NULL when DaVinci EMAC is down (using ifconfig eth0 down).
So when MAC address is changed using ifconfig eth0 hw ether 00:11:22:33:44:55,
emac_dev_setmac_addr() performs an illegal access to rxch-mac_addr, which
causes a kernel oops.
Signed-off-by: Pablo Bitton pablo.bit...@gmail.com
---
drivers/net/davinci_emac.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index cf689a0..cd114d9 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -1823,9 +1823,14 @@ static int emac_dev_setmac_addr(struct net_device *ndev,
void *addr)
/* Store mac addr in priv and rx channel and set it in EMAC hw */
memcpy(priv-mac_addr, sa-sa_data, ndev-addr_len);
- memcpy(rxch-mac_addr, sa-sa_data, ndev-addr_len);
memcpy(ndev-dev_addr, sa-sa_data, ndev-addr_len);
- emac_setmac(priv, EMAC_DEF_RX_CH, rxch-mac_addr);
+
+ /* If the interface is down - rxch is NULL. */
+ /* MAC address is configured only after the interface is enabled. */
+ if (netif_running(ndev)) {
+ memcpy(rxch-mac_addr, sa-sa_data, ndev-addr_len);
+ emac_setmac(priv, EMAC_DEF_RX_CH, rxch-mac_addr);
+ }
if (netif_msg_drv(priv))
dev_notice(emac_dev, DaVinci EMAC: emac_dev_setmac_addr %s\n,
--
1.5.4.3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Missing attachment at DaVinci wiki
Hello, I've tried to follow http://wiki.davincidsp.com/index.php/Building_DSPLink_with_kbuild to build DSPLink module and sample applications. But it seems that 1.61patchTo2_6_28.patch is missing from the wiki page. Could you please post it again? Thanks in advance, Pablo. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
A question about MUSB driver
Hello to all, I have a question about davinci_source_power() function at drivers/usb/musb/davinci.c (http://lxr.linux.no/linux+v2.6.30/drivers/usb/musb/davinci.c#L170). If I am not wrong, it is using #ifdef CONFIG_MACH_DAVINCI_EVM and machine_is_davinci_evm() macro to conditionally turn VBUS-controlling GPIO on and off, depending on specific machine being DaVinci EVM. Our team works on another DaVinci based board - that is based on the EVM, but has different machine ID and uses different GPIO for VBUS switching. If we use davinci.c code without a change, it is compiled without VBUS handling code at all, which is certainly not what we need. How should we change the code/Makefile/build process to include VBUS handling for out specific board? Thanks in advance. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Fwd: DM6446 Ethernet MAC performance
From: Pablo Bitton pablo.bit...@gmail.com Date: Mon, Mar 2, 2009 at 11:52 AM Subject: Re: DM6446 Ethernet MAC performance To: Subrahmanya, Chaithrika chaithr...@ti.com Hi, I've found that the issue below can be demonstrated by compiling the following two revisions: http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=commit;h=73af72ed66644dc3703b0bfd74285f30f1fe408f - before PHY refactoring http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=commit;h=b2cbe2f96aa420efcd312a1de8f7fd8e511b2a55 - after PHY refactoring Build commands used: $ make distclean $ make davinci_dm644x_evm_defconfig $ make uImage The kernels above were loaded to the same EVM, using the same network setup - and had the following performace: 73af72ed66644dc3703b0bfd74285f30f1fe408f - 72Mbit/s (upload) b2cbe2f96aa420efcd312a1de8f7fd8e511b2a55 - 21Mbit/s (upload) This experiment was repeated several times, so probably network congestion is not the reason for performance degradation seen. Regards, Pablo. On Wed, Feb 25, 2009 at 7:44 PM, Pablo Bitton pablo.bit...@gmail.com wrote: My host is Ubuntu 8.04, running over VMware, connected to DVEVM by 2 switches. I agree that this setup may cause network congestion. However, I've ran iperf over DVEVM and the host several times - and the results were pretty much the same. The only thing that made the throughput to change dramatically was switching back and forth between 2.6.29-rc4 and 2.6.28-rc6. How should I debug this issue? Are there any recommended profiling tools for kernel's network performance? Thanks in advance. On Tue, Feb 24, 2009 at 1:39 PM, Subrahmanya, Chaithrika chaithr...@ti.com wrote: Hi to all, I've tested Linux kernel 2.6.29-rc4-davinci1 (http://git.kernel.org/?p=linux/kernel/git/khilman/linux- davinci.git;a=commit;h=582ad6bcceb7c8f0c828e71e810fd40fed7af6c3) for Ethernet performance. Kernel was compiled was done by CodeSourcery 2008q3 (gcc 4.3.2) using davinci_evm_dm644x_defconfig. After booting, iperf v2.0.4 was run on the target (DVEVM board) and on the host PC (Ubuntu 8.04) for ten seconds (using default settings): target - target (over localhost): 190Mbit/s host (connecting to) - target: 31Mbit/s target (connecting to) - host: 71Mbit/s Do the values above make sense? Can anyone confirm them? The PHY layer should not cause any decrease in the performance as it is used only to access the PHY using the MII. Please provide some more details like the connection setup used- whether it was on a network or back to back. The network dynamics will alter the performance. Regards, Chaithrika Thanks in advance. P.S. When running the same test on 2.6.28-rc6 (from http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git), before PHY was refactored out from davinci_emac, the results were better: host (connecting to) - target: 73Mbit/s target (connecting to) - host: 57Mbit/s ___ 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: DM6446 Ethernet MAC performance
My host is Ubuntu 8.04, running over VMware, connected to DVEVM by 2 switches. I agree that this setup may cause network congestion. However, I've ran iperf over DVEVM and the host several times - and the results were pretty much the same. The only thing that made the throughput to change dramatically was switching back and forth between 2.6.29-rc4 and 2.6.28-rc6. How should I debug this issue? Are there any recommended profiling tools for kernel's network performance? Thanks in advance. On Tue, Feb 24, 2009 at 1:39 PM, Subrahmanya, Chaithrika chaithr...@ti.com wrote: Hi to all, I've tested Linux kernel 2.6.29-rc4-davinci1 (http://git.kernel.org/?p=linux/kernel/git/khilman/linux- davinci.git;a=commit;h=582ad6bcceb7c8f0c828e71e810fd40fed7af6c3) for Ethernet performance. Kernel was compiled was done by CodeSourcery 2008q3 (gcc 4.3.2) using davinci_evm_dm644x_defconfig. After booting, iperf v2.0.4 was run on the target (DVEVM board) and on the host PC (Ubuntu 8.04) for ten seconds (using default settings): target - target (over localhost): 190Mbit/s host (connecting to) - target: 31Mbit/s target (connecting to) - host: 71Mbit/s Do the values above make sense? Can anyone confirm them? The PHY layer should not cause any decrease in the performance as it is used only to access the PHY using the MII. Please provide some more details like the connection setup used- whether it was on a network or back to back. The network dynamics will alter the performance. Regards, Chaithrika Thanks in advance. P.S. When running the same test on 2.6.28-rc6 (from http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git), before PHY was refactored out from davinci_emac, the results were better: host (connecting to) - target: 73Mbit/s target (connecting to) - host: 57Mbit/s ___ 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
DM6446 Ethernet MAC performance
Hi to all, I've tested Linux kernel 2.6.29-rc4-davinci1 (http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=commit;h=582ad6bcceb7c8f0c828e71e810fd40fed7af6c3) for Ethernet performance. Kernel was compiled was done by CodeSourcery 2008q3 (gcc 4.3.2) using davinci_evm_dm644x_defconfig. After booting, iperf v2.0.4 was run on the target (DVEVM board) and on the host PC (Ubuntu 8.04) for ten seconds (using default settings): target - target (over localhost): 190Mbit/s host (connecting to) - target: 31Mbit/s target (connecting to) - host: 71Mbit/s Do the values above make sense? Can anyone confirm them? Thanks in advance. P.S. When running the same test on 2.6.28-rc6 (from http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git), before PHY was refactored out from davinci_emac, the results were better: host (connecting to) - target: 73Mbit/s target (connecting to) - host: 57Mbit/s ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Strange problem with Linux git version. lcd crashes ttyS0 console! goto USB problem now
Hey, I've got the same Oops as you. It seems that all you need to do is modprobe pcf857x before you modprobe musb_hdrc. By the way, I think it's better to build pcf857x driver as a part of the kernel image. Good luck. 2008/10/30 BlackSword [EMAIL PROTECTED]: Hi all, any body have some idea about: While compile Device Drivers-USB Support-Inventra Highspeed Dual Role Controller (TI, ...) to Y. (means compiled into the kernel). System will also panic。 below is the log: Uncompressing Linux. ... done, booting the kernel. 5Linux version 2.6.27-rc6-davinci1 ([EMAIL PROTECTED]) (gcc version 4.3.2 (GCC ) ) #23 PREEMPT Thu Oct 30 01:04:56 CST 2008 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 Machine: DaVinci EVM Memory policy: ECC disabled, Data cache writeback 7On node 0 totalpages: 51200 7free_area_init_node: node 0, pgdat c02ede3c, node_mem_map c031b000 7 DMA zone: 32512 pages, LIFO batch:7 7 Normal zone: 18288 pages, LIFO batch:3 DaVinci DM6446 variant 0x0 CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets CPU0: D cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets Built 1 zonelists in Zone order, mobility grouping on. Total pages: 50800 5Kernel command line: console=ttyS0,115200n8 noinitrd rw ip=192.168.23.99 root =/dev/nfs nfsroot=192.168.23.3:/opt/fileroot,nolock mem=200M video=davincifb:out put=lcd PID hash table entries: 1024 (order: 10, 4096 bytes) Console: colour dummy device 80x30 6Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) 6Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) 6Memory: 200MB = 200MB total 5Memory: 199612KB available (2740K code, 264K data, 128K init) 6Calibrating delay loop... 147.86 BogoMIPS (lpj=739328) Mount-cache hash table entries: 512 6CPU: Testing write buffer coherency: ok 7device: 'platform': device_add 7bus: 'platform': registered 7Registering sysdev class 'cpu' 6net_namespace: 804 bytes nbs p; 6NET: Registered protocol family 16 7device class 'bdi': registering 7device class 'video_output': registering 7device class 'tty': registering 7device class 'vtconsole': registering 7device: 'vtcon0': device_add 4WARNING: both IDE and NOR flash are enabled, but share pins. Disable IDE for NOR support. 7Registering platform device 'physmap-flash.0'. Parent at platform 7device: 'physmap-flash.0': device_add 7bus: 'platform': add device physmap-flash.0 7Registering platform device 'davinci_nand.0'. Parent at platform 7device: 'davinci_nand.0': device_add 7bus: 'platform': add device davinci_nand.0 7Registering platform device 'davincifb'. Parent at platform 7device: 'davincifb': device_add 7bus: 'platform': add device davincifb 7Registering platform device 'rtc_davinci_evm'. Parent at platform 7device: 'rtc_davinci_evm': device_add 7bus: 'platform': add device rtc_davinci_evm 7Registering platform device 'palm_bk3710'. Parent at platform 7device: 'palm_bk3710': device_add 7bus: 'platform': add device palm_bk3710 7Registering platform device 'i2c_davinci.1'. Parent at platform 7device: 'i2c_davinci.1': device_add 7bus: 'platform': add device i2c_davinci.1 7Registering platform device 'musb_hdrc'. Parent at platform 7device: 'musb_hdrc': device_add 7bus: 'platform': add device musb_hdrc 7Registering platform device 'serial8250.0'. Parent at platform 7device: 'serial8250.0': device_add 7bus: 'platform': add device serial8250.0 6DaVinci: 71 gpio irqs 7Registering platform device 'davinci_mmc.1'. Parent at platform 7device: 'davinci_mmc.1': device_add 7bus: 'platform': add device davinci_mmc.1 7Registering sys device of class 'cpu' 7Registering sys device 'cpu0' 7device: 'default': device_add 7device class 'block': registering 7device class 'graphics': registering 7device class 'misc': registering 7bus: 'serio': registered 7bus: 'i2c': registered 7device class 'i2c-adapter': registering nbs p; 7bus: 'i2c': add driver dummy 7bus: 'platform': add driver i2c_davinci 7bus: 'platform': driver_probe_device: matched device i2c_davinci.1 with drive r i2c_davinci 7bus: 'platform': really_probe: probing driver i2c_davinci with device i2c_dav inci.1 7device: 'i2c-1': device_add 7device: '1-0038': device_add 7bus: 'i2c': add device 1-0038 nbsp ; 7device: '1-0039': device_add 7bus: 'i2c': add device 1-0039 7device: '1-003a': device_add nbs p; 7bus: 'i2c': add device 1-003a 7device: '1-0050': device_add 7bus: 'i2c': add device 1-0050 nb sp; 7driver: 'i2c_davinci.1': driver_bound: bound to device
Build error in RTC driver for DVEVM
Hi to all, I have checked out the latest kernel version from here: http://source.mvista.com/git/?p=linux-davinci-2.6.git;a=commit;h=a02b8fef27d8590e039a78f559146bb9ae36fe04 I am using CodeSourcery's toolchain from here: http://www.codesourcery.com/gnu_toolchains/arm/portal/release324 After unpacking and setting ARCH and CROSS_COMPILE, I ran the following commands: $ make distclean $ make davinci_evm_dm644x_defconfig $ make uImage $ make modules The last build command failed with the following error message: CC [M] drivers/rtc/rtc-davinci-evm.o drivers/rtc/rtc-davinci-evm.c:33:29 error: mach/i2c-client.h: No such file or directory It seems that the file i2c-client.h was deleted by the commit above (a02b8fef27d8590e039a78f559146bb9ae36fe04), but the drivers/rtc/rtc-davinci-evm.c still depends on it. Am I correct? Thanks in advance. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
