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
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
Re: Missing attachment at DaVinci wiki
Thanks a lot! On Thu, Jun 25, 2009 at 8:02 AM, Kamoolkar, Mugdha wrote: > Hi, > > > > I have updated the link again. > > > > Regards, > Mugdha > > > ------ > > *From:* Pablo Bitton [mailto:pablo.bit...@gmail.com] > *Sent:* Wednesday, June 24, 2009 10:44 PM > *To:* Kamoolkar, Mugdha; davinci-linux-open-source@linux.davincidsp.com > *Subject:* 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
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, Sekhar 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
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
---
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
[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
Signed-off-by: Chaithrika U S
Tested-by: Chaithrika U S
[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.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
Signed-off-by: Chaithrika U S
Tested-by: Chaithrika U S
[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 Bitton 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
> Signed-off-by: Chaithrika U S
> Tested-by: Chaithrika U S
> [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: Problem regarding DSPLink build
I can recommend building DSPLink using OE/Arago: https://gforge.ti.com/gf/project/arago/mailman/?_forum_action=ForumMessageBrowse&thread_id=2096&action=ListThreads&mailman_id=39 On Fri, Jul 31, 2009 at 11:43 AM, Vijayabharathi C 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] 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
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
Signed-off-by: Pablo Bitton
---
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
#include
#include
+#include
#include
@@ -28,6 +29,7 @@
#include
#include
#include
+#include
#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
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
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 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
Fwd: DM6446 Ethernet MAC performance
From: Pablo Bitton Date: Mon, Mar 2, 2009 at 11:52 AM Subject: Re: DM6446 Ethernet MAC performance To: "Subrahmanya, Chaithrika" 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 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 > 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
Hi,
I forgot to mention that I've used iperf's TCP throughput test, with the
following settings:
$ iperf -s # for running a TCP server
$ iperf -c {server's IP address} -i 1 # for running a TCP client
Thanks for helping me out,
Pablo.
On Mon, Mar 2, 2009 at 3:54 PM, Subrahmanya, Chaithrika
wrote:
> > From: Pablo Bitton
> > Date: Mon, Mar 2, 2009 at 11:52 AM
> > Subject: Re: DM6446 Ethernet MAC performance
> > To: "Subrahmanya, Chaithrika"
> >
> >
> > 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.
> >
>
> I am looking into this issue, will get back to you with my findings.
> I have not observed any large difference in performance numbers
> when I tested it earlier (for UDP). In fact there was some
> improvement for some cases.
>
> Thanks,
> Chaithrika
>
> > Regards,
> > Pablo.
> >
> > On Wed, Feb 25, 2009 at 7:44 PM, Pablo Bitton
> > 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
> > > 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
>
___
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
leep
is false.
2) The to_cnt static var never increments beyond 1. 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.
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.
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
--
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
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
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. > <5>Linux 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 > <7>On node 0 totalpages: > 51200 > <7>free_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 > <5>Kernel 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 > <6>Dentry cache hash table entries: 32768 (order: 5, 131072 > bytes) > <6>Inode-cache hash table entries: 16384 (order: 4, 65536 > bytes) > <6>Memory: 200MB = 200MB > total > <5>Memory: 199612KB available (2740K code, 264K data, 128K > init) > <6>Calibrating delay loop... 147.86 BogoMIPS > (lpj=739328) > Mount-cache hash table entries: > 512 > <6>CPU: Testing write buffer coherency: > ok > <7>device: 'platform': > device_add > <7>bus: 'platform': > registered > <7>Registering sysdev class > 'cpu' > <6>net_namespace: 804 > bytes &nbs p; > <6>NET: Registered protocol family > 16 > <7>device class 'bdi': > registering > <7>device class 'video_output': > registering > <7>device class 'tty': > registering > <7>device class 'vtconsole': > registering > <7>device: 'vtcon0': > device_add > <4>WARNING: both IDE and NOR flash are enabled, but share > pins. > Disable IDE for NOR > support. > <7>Registering platform device 'physmap-flash.0'. Parent at > platform > <7>device: 'physmap-flash.0': > device_add > <7>bus: 'platform': add device > physmap-flash.0 > <7>Registering platform device 'davinci_nand.0'. Parent at > platform > <7>device: 'davinci_nand.0': > device_add > <7>bus: 'platform': add device > davinci_nand.0 > <7>Registering platform device 'davincifb'. Parent at > platform > <7>device: 'davincifb': > device_add > <7>bus: 'platform': add device > davincifb > <7>Registering platform device 'rtc_davinci_evm'. Parent at > platform > <7>device: 'rtc_davinci_evm': > device_add > <7>bus: 'platform': add device > rtc_davinci_evm > <7>Registering platform device 'palm_bk3710'. Parent at > platform > <7>device: 'palm_bk3710': > device_add > <7>bus: 'platform': add device > palm_bk3710 > <7>Registering platform device 'i2c_davinci.1'. Parent at > platform > <7>device: 'i2c_davinci.1': > device_add > <7>bus: 'platform': add device > i2c_davinci.1 > <7>Registering platform device 'musb_hdrc'. Parent at > platform > <7>device: 'musb_hdrc': > device_add > <7>bus: 'platform': add device > musb_hdrc > <7>Registering platform device 'serial8250.0'. Parent at > platform > <7>device: 'serial8250.0': > device_add > <7>bus: 'platform': add device > serial8250.0 > <6>DaVinci: 71 gpio > irqs > <7>Registering platform device 'davinci_mmc.1'. Parent at > platform > <7>device: 'davinci_mmc.1': > device_add > <7>bus: 'platform': add device > davinci_mmc.1 > <7>Registering sys device of class > 'cpu' > <7>Registering sys device > 'cpu0' > <7>device: 'default': > device_add > <7>device class 'block': > registering > <7>device class 'graphics': > registering > <7>device class 'misc': > registering > <7>bus: 'serio': > registered > <7>bus: 'i2c': > registered > <7>device class 'i2c-adapter': > registering &nbs p; > <7>bus: 'i2c': add driver > dummy > <7>bus: 'platform': add driver > i2c_davinci > <7>bus: 'platform': driver_probe_device: matched device i2c_davinci.1 with > drive > r > i2c_davinci > <7>bus: 'platform': really_probe: probing driver i2c_davinci with device > i2c_dav > inci.1 > <7>device: 'i2c-1': > device_add > <7>device: '1-0038': > device_add > <7>bus: 'i2c': add device > 1-0038 ; > <7>device: '1-0039': > device_add > <7>bus:
