Re: moved on to a kernel cmem problem
I have been over the memory map a dozen times. I have set my mem parameter in the bootargs to as much as 10 megs lower than the start of my cmem region. I have given DSPLINK more than enough space in the codec servers memory map and have adjusted the dsplink's memory map to match. No matter what I do, when the dsplink code gets to either mutex_lock_interruptible or mutex_unlock it crashes with the kernel paging error. I have commented out these functions as an experiment and it stops crashing. It does not work correctly because everything tries to access it at once without the locks, but it keeps going. As another experiment I tried messing up the memory map slightly, or filling all the shared memory with the linux section. And all of these fail with a different error. It really seems to me that the dsplink is not properly linking against the kernel and it is not able to find the specific code for the mutex library. Maybe I am not setting something correctly in the make files. I have also tried using the wiki's instruction for creating a makefile with kbuild. Same problem. Thanks for your reply. Any additional help would be great. -mat On Mon, Apr 13, 2009 at 1:26 AM, Kamoolkar, Mugdha mug...@ti.com wrote: Mat, We have verified DSPLink with 2.6.18+ versions (notably 2.6.22 and 2.6.23, and later even latest GIT versions). There is no issue of the sort that you have mentioned below. The folder says 2.6.18 because there’s no difference as far as DSPLink is concerned between 2.6.18 and later versions that we have tested with. So this (2.6.18) actually means 2.6.18+. DSPLink requires some shared memory which is removed from Linux address space using appropriate mem= parameter in bootargs. In default configuration, it’s 2MB. You can look here for more details: http://tiexpressdsp.com/index.php?title=Changing_the_DVEVM_memory_map Regards, Mugdha -- *From:* davinci-linux-open-source-boun...@linux.davincidsp.com [mailto: davinci-linux-open-source-boun...@linux.davincidsp.com] *On Behalf Of *Mat Laibowitz *Sent:* Monday, April 13, 2009 4:20 AM *To:* davinci-linux-open-source@linux.davincidsp.com *Subject:* Re: moved on to a kernel cmem problem Changing the mutex functions to rt_mutex functions did not help, neither did include mutex.h. I also tried following the instructions on the wiki here: http://tiexpressdsp.com/index.php?title=Building_DSPLink_with_kbuild and this will successfully build the dsplink, but it still exits with a kernel error on mutex_lock. -mat On Sun, Apr 12, 2009 at 4:32 PM, Mat Laibowitz mlaibow.davi...@gmail.com wrote: After trying to play around with the memory map some more, I did a little more digging. It seems that the function that fails, according to the oops, is SYNC_SpinLockStartEx, which is in the dsplink source file sync.c located in gpp/src/osal/Linux/2.6.18. Considering that the folder is called 2.6.18, there might be a kernel version problem with my 2.6.22 kernel. Within the SYNC_SpinLockStartEx function, the specific call that fails is mutex_lock_interruptible. The sync.c file includes rtmutex.h from the kernel includes. The actual function call for mutex_lock_interruptible that is in rtmutex.h is rt_mutex_lock_interruptible. The call mutex_lock_interruptible is not actual in rtmutex.h and it is in mutex.h which as far as I can tell is not included in sync.c. Dsplink version 1.4 does not use mutexes in its sync.c file. I think it turns on and off irqs to protect critical sections. I am going to try to change all the calls in sync.c to rt_ and recompile and see if it works. -mat On Sun, Apr 12, 2009 at 3:14 PM, Mat Laibowitz mlaibow.davi...@gmail.com wrote: Thanks for the replies. I am using kernel 2.6.22 and dsplink 1.60. Maybe your findings could help even if these are different versions. From what you guys are saying, it seems that the app is looking for dsplink and not finding it? When you change the bootarg to mem=118M do you also change the cmem location or do you leave a gap between the linux section and the cmem section? Does this effect the dsplink somehow? Also, if I am using NSF and the root directory on the nsf partition contains more than 120M worth of files, will this cause a problem? Thanks again, -mat On Sun, Apr 12, 2009 at 8:48 AM, Steve Chen sc...@mvista.com wrote: On Sun, 2009-04-12 at 10:08 +0300, Yusuf Caglar AKYUZ wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mat Laibowitz wrote: In order to debug my mpeg4dec app side program I was looking dmai to see how it accessed the viddec2 ce interface. Along the way I decided to try and compile it and also to try and upgrade some components. I modified the dmai source to support my custom board and can compile it. Now I am having a run-time issue with the codec engine. I am just trying to run the decode demo. I get the error:
Re: moved on to a kernel cmem problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mat Laibowitz wrote: I have been over the memory map a dozen times. I have set my mem parameter in the bootargs to as much as 10 megs lower than the start of my cmem region. I have given DSPLINK more than enough space in the codec servers memory map and have adjusted the dsplink's memory map to match. No matter what I do, when the dsplink code gets to either mutex_lock_interruptible or mutex_unlock it crashes with the kernel paging error. I have commented out these functions as an experiment and it stops crashing. It does not work correctly because everything tries to access it at once without the locks, but it keeps going. As another experiment I tried messing up the memory map slightly, or filling all the shared memory with the linux section. And all of these fail with a different error. It really seems to me that the dsplink is not properly linking against the kernel and it is not able to find the specific code for the mutex library. Maybe I am not setting something correctly in the make files. I have also tried using the wiki's instruction for creating a makefile with kbuild. Same problem. Thanks for your reply. Any additional help would be great. -mat As I said I had *very* similar problem and I thought there was a problem with mutex handling in my Dsplink/kernel combination. My tentavive fix is at [1]. However, later my problems did not ended, and I downgraded my Dsplink version to 1.40. 1.40 was more stable than 1.60 for me. But later on I hit a kernel bug which is present in 2.6.28 but not in 2.6.27/29, please see [2]. After applying that fix, no more Dsplink problems( at least for now). However, I never tried 1.60 again. Regards, Caglar [1] http://linux.omap.com/pipermail/davinci-linux-open-source/2009-March/011647.html [2] http://www.spinics.net/lists/arm-kernel/msg62873.html -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkni/NMACgkQ/nL+S5dojej/9wCguUPFo3O2nntGg00gd1X0Nu6C S74AoJM2aM4i84vBe63dWp5JcGUIhBe3 =wVlS -END PGP SIGNATURE- ___ 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] ARM: DaVinci: EMAC: Fix alignment traps on packet reception
From: Troy Kisky [mailto:troy.ki...@boundarydevices.com]
Sent: Saturday, April 11, 2009 7:17 AM
nsek...@ti.com wrote:
From: Steve Chen [sc...@mvista.com]
[...]
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 635e31f..eecd983 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -349,6 +349,17 @@ static const char emac_version_string[] = TI
DaVinci EMAC Linux v6.0;
#define EMAC_DM646X_MAC_EOI_C0_RXEN(0x01)
#define EMAC_DM646X_MAC_EOI_C0_TXEN(0x02)
+/*
+ * L3 Alignment mechanism: The below given macro returns the number
of
+ * bytes required to align the given size to a L3 frame 4 byte
+ * boundry. This is typically required to add 2 bytes to the
ethernet
+ * frame start to make sure the IP header (L3) is aligned on a 4
byte
+ * boundry
+ */
+static char emac_L3_align[] = { 0x02, 0x01, 0x00, 0x03 };
+
+#define EMAC_L3_ALIGN(size)emac_L3_align[(size) 0x3]
How about
#define EMAC_L3_ALIGN(size) (((2-(size)) 0x3)
Thanks, I will make this change.
Regards,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: moved on to a kernel cmem problem
Yes, a very similar problem indeed. I tried your patch from [1], and the problem did go away. The code no longer crashes with a kernel paging error! This is major progress, thanks. I am still not able to get the video decoder codecs that use viddec2 interface to work, but not at least I have a working dsplink and a working dmai. So I should be able to get the codec servers to work. Thanks again, -mat On Mon, Apr 13, 2009 at 4:50 AM, Yusuf Caglar AKYUZ caglarak...@gmail.comwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mat Laibowitz wrote: I have been over the memory map a dozen times. I have set my mem parameter in the bootargs to as much as 10 megs lower than the start of my cmem region. I have given DSPLINK more than enough space in the codec servers memory map and have adjusted the dsplink's memory map to match. No matter what I do, when the dsplink code gets to either mutex_lock_interruptible or mutex_unlock it crashes with the kernel paging error. I have commented out these functions as an experiment and it stops crashing. It does not work correctly because everything tries to access it at once without the locks, but it keeps going. As another experiment I tried messing up the memory map slightly, or filling all the shared memory with the linux section. And all of these fail with a different error. It really seems to me that the dsplink is not properly linking against the kernel and it is not able to find the specific code for the mutex library. Maybe I am not setting something correctly in the make files. I have also tried using the wiki's instruction for creating a makefile with kbuild. Same problem. Thanks for your reply. Any additional help would be great. -mat As I said I had *very* similar problem and I thought there was a problem with mutex handling in my Dsplink/kernel combination. My tentavive fix is at [1]. However, later my problems did not ended, and I downgraded my Dsplink version to 1.40. 1.40 was more stable than 1.60 for me. But later on I hit a kernel bug which is present in 2.6.28 but not in 2.6.27/29, please see [2]. After applying that fix, no more Dsplink problems( at least for now). However, I never tried 1.60 again. Regards, Caglar [1] http://linux.omap.com/pipermail/davinci-linux-open-source/2009-March/011647.html [2] http://www.spinics.net/lists/arm-kernel/msg62873.html -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkni/NMACgkQ/nL+S5dojej/9wCguUPFo3O2nntGg00gd1X0Nu6C S74AoJM2aM4i84vBe63dWp5JcGUIhBe3 =wVlS -END PGP SIGNATURE- ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Need Help : Please reply ASAp
Hi, I need to test the various peripheral device and drivers available on the TI Davinci DM 644x board. For the I have gone through the available test provided by the TI (functional and performance). But these test contains test cases for only few peripherals. I need to test for all other peripherals. I am looking for drivers user guide for da vinci DM644x board. from where I will come to know which API are available and whats their role. What are the parameters user can pass ? Please share your knowledge with me. I have sent a mail earlier also. but no body has replied till now Thanks Yogesh http://www.mindtree.com/email/disclaimer.html ___ 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 0/4] ARM: DaVinci: DM646x Video: DM646x display driver
On Wednesday 08 April 2009 13:17:56 Chaithrika U S wrote: Display driver for TI DM646x EVM Signed-off-by: Manjunath Hadli m...@ti.com Signed-off-by: Brijesh Jadav brijes...@ti.com Signed-off-by: Chaithrika U S chaithr...@ti.com These patches add the display driver support for TI DM646x EVM. This patch set has been tested for basic display functionality for Composite and Component outputs. In this version of the patches, the review comments got for the earlier version have been incorporated. The standard information(timings) has been moved to the display driver. The display driver has been modified accordingly. Also simplified the code by removing the redundant vpif_stdinfo data structure. Patch 1: Display device platform and board setup Patch 2: VPIF driver Patch 3: DM646x display driver Patch 4: Makefile and config files modifications for Display Some of the features like the HBI/VBI support are not yet implemented. Also there are some known issues in the code implementation like fine tuning to be done to TRY_FMT ioctl.The USERPTR usage has not been tested extensively. Time permitting I'll review this during the weekend. During a very superficial scan I saw a few things that could be improved, but I think it only needs one more cycle before it can be merged. It looks much, much better now! Regards, Hans -Chaithrika -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Hans Verkuil - video4linux developer - sponsored by TANDBERG ___ 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] ARM: DaVinci: EMAC: Fix alignment traps on packet reception
From: Steve Chen sc...@mvista.com
The skb data allocated for packet data received is 4 byte aligned.
Unfortunately, this causes non-32bit aligned accesses in IP stack because
the MAC header is non-word aligned (14 bytes).
The result can be observed by looking at /proc/cpu/alignment while the
device is over network.
This issue is resolved by using a 2-byte extra offset in the packet buffer.
A quick performance test over lab network using iperf on DM6446 EVM showed
an increase in bandwidth from 60Mbits/s to 70Mbits/s.
Signed-off-by: Steve Chen sc...@mvista.com
Signed-off-by: Sekhar Nori nsek...@ti.com
---
drivers/net/davinci_emac.c | 21 +
1 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 635e31f..471126a 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -349,6 +349,15 @@ static const char emac_version_string[] = TI DaVinci EMAC
Linux v6.0;
#define EMAC_DM646X_MAC_EOI_C0_RXEN(0x01)
#define EMAC_DM646X_MAC_EOI_C0_TXEN(0x02)
+/*
+ * L3 Alignment mechanism: The below given macro returns the number of
+ * bytes required to align the given size to a L3 frame 4 byte
+ * boundry. This is typically required to add 2 bytes to the ethernet
+ * frame start to make sure the IP header (L3) is aligned on a 4 byte
+ * boundry
+ */
+#define EMAC_L3_ALIGN(size)((2 - (size)) 0x3)
+
/** net_buf_obj: EMAC network bufferdata structure
*
* EMAC network buffer data structure
@@ -1560,7 +1569,8 @@ static void *emac_net_alloc_rx_buf(struct emac_priv
*priv, int buf_size,
/* set device pointer in skb and reserve space for extra bytes */
p_skb-dev = ndev;
- skb_reserve(p_skb, EMAC_DEF_EXTRA_RXBUF_SIZE);
+ skb_reserve(p_skb, EMAC_DEF_EXTRA_RXBUF_SIZE +
+ EMAC_L3_ALIGN(EMAC_DEF_EXTRA_RXBUF_SIZE));
*data_token = (void *) p_skb;
EMAC_CACHE_WRITEBACK_INVALIDATE((unsigned long)p_skb-data, buf_size);
return p_skb-data;
@@ -1990,8 +2000,9 @@ static int emac_rx_bdproc(struct emac_priv *priv, u32 ch,
u32 budget,
(pkts_processed budget)) {
new_buffer = emac_net_alloc_rx_buf(priv,
- EMAC_DEF_MAX_FRAME_SIZE,
- new_buf_token, EMAC_DEF_RX_CH);
+ EMAC_DEF_MAX_FRAME_SIZE +
+ EMAC_L3_ALIGN(EMAC_DEF_EXTRA_RXBUF_SIZE),
+ new_buf_token, EMAC_DEF_RX_CH);
if (unlikely(NULL == new_buffer)) {
++rxch-out_of_rx_buffers;
goto end_emac_rx_bdproc;
@@ -2411,7 +2422,9 @@ static int emac_dev_open(struct net_device *ndev)
ndev-dev_addr[cnt] = priv-mac_addr[cnt];
/* Configuration items */
- priv-rx_buf_size = EMAC_DEF_MAX_FRAME_SIZE + EMAC_DEF_EXTRA_RXBUF_SIZE;
+ priv-rx_buf_size = EMAC_DEF_MAX_FRAME_SIZE +
+ EMAC_DEF_EXTRA_RXBUF_SIZE +
+ EMAC_L3_ALIGN(EMAC_DEF_EXTRA_RXBUF_SIZE);
/* Clear basic hardware */
for (ch = 0; ch EMAC_MAX_TXRX_CHANNELS; ch++) {
--
1.6.0.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: u boot and framebuffer interface
Thanks for help. Now I am able to display logo, after enabling Framebuffer Console support in kernel config. Device Drivers - Graphics Support - Console display driver support --- * Framebuffer Console support Background for the logo is blue by default, I am successfully able to replace logo, but failed to change the background color. Can you please help me on that. Regards, Deepika Deepak Mundra wrote: Hi Seems like your driver configuration is not proper, may be your offset.. are images coming properly on display ??? .. And please from next time mail in mailing list .. it will help other people also Regards deepak On 4/10/09, *Deepika Makhija* deepika.makh...@einfochips.com mailto:deepika.makh...@einfochips.com wrote: Hello, Response is inline to previous help. Deepak Mundra wrote: hi, On 4/10/09, *Deepika Makhija* deepika.makh...@einfochips.com mailto:deepika.makh...@einfochips.com wrote: Hi, Mine is VGA 1024x768 output to touchscreen LCD. I didn't knew that Davinci Kernel, displays logo during boot, some random display patterns (Vertical lines of different colors) are observed on LCD during kernel boot up did you mean by color baar pattern ? Deepika : No Not the color bar pattern. While u-boot is loaded some random lines are observed, every time different :( then in driver/video/davincifb.c check if dispc_reg_out(VENC_VDPRO, 0x100); is enabled .. this value is set to generate colorbar pattern .. if this is line is ther just comment. and try to boot or second thing could be to make sure logo display is enabled in kernel # make menuconfig Device drivers - Graphics support - Logo configuration -bootup logo and select 224 pattern. Deepika : Default Kernel Configuration enables all three options i.e [*] Standard black and white Linux logo [*] Standard 16-color Linux logo [* ] Standard 224-color Linux logo I tried which each of them one by one, but no LOGO appeared, only black(blank) screen. process (after FB is initialized). Can u help me in that, i mean guide if i m missing something in that case Thanks, Deepika Deepak Mundra wrote: And davinci kernel already has logo display during boot up ryt, so you can replace that logo with your logo .. this will make logo to be displayed immediately after frame buffer is initialized in kernel and before filesystem is loaded.. On 4/10/09, *Deepak Mundra* deepa...@allaboutif.com mailto:deepa...@allaboutif.com wrote: Hi, Just to confirm .. are you using VGA output or composit .. coz a s i mentioned earlier for me it is taking time in ths8200 chip initialization code.. coz it uses i2c writes almost in 20+ adress which was taking time .. and i felt like it is coz of i2c driver used in uboot 1.2.0 .. So my suggetion is that in case if you are not using ths8200 chip you can go ahead with that .. and i feel that in latest uboot it should work fine.. you can go throgh following link for davincifb support in uboot 1.3.x+ ..i had to do little work to pul it down to 1.2.0 .. http://github.com/neuros/u-boot/commit/689195c1865b79f745bcf145a809464dec2f391f Thanks Regards Deepak. On 4/10/09, *Deepika Makhija* deepika.makh...@einfochips.com mailto:deepika.makh...@einfochips.com wrote: Hello Deepak, Thanks for your inputs. Actually I wanted to display a logo, till the system boots up. I am working on DM355 based product, in which it few sec's to initialize the everything (ubl,U-boot,kernel,filesystem), so i thought to display something till the board is up, but if this adds 3/4 sec delay in boot up process than it is of no use for me. I guess, I have to think of some other option like initialize video interface earlier in kernel and display LOGO from the kernel, because loading filesystem from NAND eats up much of the booting time. Thanks for your help Regards, Deepika Deepak Mundra wrote: Hello Deepika, I am working with dm6446 .. and we r using vga output .. actulauly i was able to enable framebuffer support in uboot and display colorbaar pattern and also diffrent colors.. but couldnt draw any images.. actualy i found that when initializing framebuffer THS8200 is
Help: about mcbsq aic23b on dm6446
Hi, i work with dm6446 on Linux 2.6.10 MV Kernel. Now i test the audio, but i have some trouble. the aic23b is the master mode. the msbsq is the slave mode. when play music , i only hear a lot of noise but can not hear any music. when record music, i just hear a lot of noise with some music. have anyone faced the problem ? thanks alana ___ 好玩贺卡等你发，邮箱贺卡全新上线！ http://card.mail.cn.yahoo.com/ ___ 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: Help: about mcbsq aic23b on dm6446
On Mon, 2009-04-13 at 21:46 +0800, airpla...@yahoo.com.cn wrote: Hi, i work with dm6446 on Linux 2.6.10 MV Kernel. Now i test the audio, but i have some trouble. the aic23b is the master mode. the msbsq is the slave mode. when play music , i only hear a lot of noise but can not hear any music. when record music, i just hear a lot of noise with some music. have anyone faced the problem ? I tried madplay and wavplay on dm6446 EVM with 2.6.10 kernel sometime ago. Both applications worked for me. 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
Re: [PATCH] ARM: DaVinci: EMAC: Fix alignment traps on packet reception
On Friday 10 April 2009, nsek...@ti.com wrote: This issue is resolved by using a 2-byte extra offset in the packet buffer. Isn't the issue that NET_IP_ALIGN is supposed to resolve, when properly used by network drivers? ___ 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 and DM9000 Ethernet
-Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of David Brownell Sent: Thursday, April 09, 2009 5:44 PM To: Tom Wheeler Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: DM355 and DM9000 Ethernet On Thursday 09 April 2009, Tom Wheeler wrote: I have had problems getting the dm9000 mac/phy working properly with the DM355 EVM. I have seen a number of posts indicating problems with the dm9000 and the DM355. In my case, enabling LOCKDEP is sufficient to make all of those problems vanish ... a dm9000 IRQ handler bugfix made *some* of the problems go away. (e3162d381fc359ebe5c98a3e216888a7cb200051 is in 2.6.29 and thus DaVinci GIT.) The 2.6.18 kernel requests the individual interrupt for GPIO1 (IRQ 45) where the 2.6.28 kernel uses the gpio controller interrupt (IRQ 65) which is chained to the bank interrupt. By changing the 2.6.28 kernel to reflect what I saw in the 2.6.18 kernel this seemed to solve the problems I was seeing. How did you get the direct GPIO IRQ to work? Did you have to disable its bank IRQ or anything? Last time I tried to use those direct IRQs, they didn't work at all. Are there known issues with the DM355 gpio controller interrupt handling where it chains the individual interrupts to the bank interrupt? So far as I know, the DM355 EVM is the first DaVinci board to make heavy use of GPIO IRQs. So it's plausible that there be some kind of load-dependent bug there. There's no confirmation of such a bug in IRQ handling, though. I'm moderately convinced there *is* a timing bug affecting that EVM, but whether it's EMIF bus timings or some IRQ handling race is an open question. Looks like, the GPIO driver does not have a provision to setup dedicated GPIO interrupts (GPIO0 - GPIO9). The current driver assumes GPIO bank interrupts. For example GPIOBNK0 interrupt is used for GPIO0 - GPIO15, even though we have dedicated GPIO interrupts for GPIO0 - GPIO9. Passing GPIO1 - 45 as the interrupt resource (start, end), but using chained interrupt IRQ 65 while calling set_irq_type has solved the dm9000 problem for Tom. The new DM365 device does not have bank interrupts, in which case we have to add support for dedicated GPIO interrupts in the GPIO driver. DM365 has GPIO0 - GPIO15 dedicated GPIO interrupts to ARM. Thanks Sneha - Dave ___ 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
Codec compilation error
hi all, i was using old compilation tools v1.2 and when i moved to v2.0 i can not compile with the following error -- --- making package.mak (because of package.bld) ... generating interfaces for package ceapp (because package/package.xdc.inc is older than package.xdc) ... configuring ceapp.x470MV from package/cfg/ceapp_x470MV.cfg ... Info: Configuring engine named 'decode_slice_server' from the info file for DSP server './decode_slice_server.x64P', located in package 'servers.decode_slice_server.evmDM6446': Target app will look for the DSP server image 'decode_slice_server.x64P' in its current directory. Adding codec 'decode_slice' (codecs.decode_slice.DECODE_SLICE), scratch groupId=0 Info: Reading DSP memory map from the info file for DSP server './decode_slice_server.x64P', located in package 'servers.decode_slice_server.evmDM6446': will link with ti.sdo.ce.utils.trace:lib/release/TraceUtil.av5T will link with ti.sdo.ce.bioslog:lib/release/bioslog.av5T will link with codecs.decode_slice:lib/decode_slice.a470MV js: /opt/xdc_3_00_02/packages/xdc/cfg/Main.xs, line 28: XDC runtime error: can't find the library 'lib/decode_slice.a470MV' specified by package codecs.decode_slice. It wasn't found along the path '/ESDU/Wasiem/filesys/ffmpeg-porting/esdu_decode_slice;/opt/dvsdk_1_30_01_41/codec_engine_2_00_01/packages;/opt/dvsdk_1_30_01_41/xdais_6_00_01/packages;/opt/dvsdk_1_30_01_41/dsplink-1_60-prebuilt/packages;/opt/framework_components_2_22_01/fctools/packages;/opt/dvsdk_1_30_01_41/framework_components_2_00_01/packages;/opt/dvsdk_1_30_01_41/biosutils_1_00_02/packages;/opt/bios_5_31_08/packages;/opt/xdc_3_00_02/packages;/opt/xdc_3_00_02/packages;..;'. gmake: *** [package/cfg/ceapp_x470MV.c] Error 1 gmake: *** Deleting file `package/cfg/ceapp_x470MV.c' gmake: *** [package/cfg/ceapp_x470MV.c] Deleting file `package/cfg/ceapp_x470MV.xdl' gmake: *** [package/cfg/ceapp_x470MV.c] Deleting file `package/cfg/ceapp_x470MV.h' js: /opt/xdc_3_00_02/packages/xdc/tools/Cmdr.xs, line 40: Error: xdc.tools.configuro: configuration failed due to earlier errors (status = 2); 'linker.cmd' deleted. make[3]: *** [ceapp] Error 1 --- i found this lib decode_slice.a470MV generated in another place other than mentioned paths and i copied this lib to the above searched paths but it also fail and i do not thing this is right way to fix above error any help is highly appreciated --- --- Mohamed AbdElwahed Ibrahim _ Show them the way! Add maps and directions to your party invites. http://www.microsoft.com/windows/windowslive/products/events.aspx___ 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] ARM: DaVinci: EMAC: Fix alignment traps on packet reception
From: David Brownell [mailto:davi...@pacbell.net] Sent: Monday, April 13, 2009 8:43 PM On Friday 10 April 2009, nsek...@ti.com wrote: This issue is resolved by using a 2-byte extra offset in the packet buffer. Isn't the issue that NET_IP_ALIGN is supposed to resolve, when properly used by network drivers? Looking at the documentation for that macro, drivers are supposed to call skb_reserve() with NET_IP_ALIGN as argument. The patch is doing the same, just not using the macro NET_IP_ALIGN. Maybe I will define the EMAC_L3_ALIGN macro as #define EMAC_L3_ALIGN(size)((NET_IP_ALIGN - (size)) 0x3) to be more clear? Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Codec compilation error
The codecs.decode_slice package is saying I have a library for the environment/configuration you're building, and it's named lib/decode_slice.a470MV. It does this via the getLibs() fxn in it's package.xs file. Just a sanity check (as this is a common error)... the codec is saying I have a library for the ARM-side of the DM644x device - is this really an ARM-side codec? (Probably not) If the codec is really a DSP-side codec, you may want to see some of the questions in this FAQ: http://tiexpressdsp.com/index.php?title=Codec_Engine_FAQ#Why_does_the_ARM_application_require_.22DSP.22_codec_packages.3F You may need to hack up the codec's package.xs getLibs() fxn as described in the FAQ to _not_ provide a library for the ARM side (assuming it's a DSP-side codec). To resolve the root cause of this, you may need to contact the codec producer (of the codecs.decode_slice package). It's hard to tell who that is by the [poor] package name - we recommend that the codec vendor name be included in the package name so that 1) it's clear who to contact(!) and 2) it's globally unique so we avoid name collisions. Chris From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Mohamed AbdElwahed Sent: Monday, April 13, 2009 8:47 AM To: Davinci Mailing list Subject: Codec compilation error hi all, i was using old compilation tools v1.2 and when i moved to v2.0 i can not compile with the following error -- --- making package.mak (because of package.bld) ... generating interfaces for package ceapp (because package/package.xdc.inc is older than package.xdc) ... configuring ceapp.x470MV from package/cfg/ceapp_x470MV.cfg ... Info: Configuring engine named 'decode_slice_server' from the info file for DSP server './decode_slice_server.x64P', located in package 'servers.decode_slice_server.evmDM6446': Target app will look for the DSP server image 'decode_slice_server.x64P' in its current directory. Adding codec 'decode_slice' (codecs.decode_slice.DECODE_SLICE), scratch groupId=0 Info: Reading DSP memory map from the info file for DSP server './decode_slice_server.x64P', located in package 'servers.decode_slice_server.evmDM6446': will link with ti.sdo.ce.utils.trace:lib/release/TraceUtil.av5T will link with ti.sdo.ce.bioslog:lib/release/bioslog.av5T will link with codecs.decode_slice:lib/decode_slice.a470MV js: /opt/xdc_3_00_02/packages/xdc/cfg/Main.xs, line 28: XDC runtime error: can't find the library 'lib/decode_slice.a470MV' specified by package codecs.decode_slice. It wasn't found along the path '/ESDU/Wasiem/filesys/ffmpeg-porting/esdu_decode_slice;/opt/dvsdk_1_30_01_41/codec_engine_2_00_01/packages;/opt/dvsdk_1_30_01_41/xdais_6_00_01/packages;/opt/dvsdk_1_30_01_41/dsplink-1_60-prebuilt/packages;/opt/framework_components_2_22_01/fctools/packages;/opt/dvsdk_1_30_01_41/framework_components_2_00_01/packages;/opt/dvsdk_1_30_01_41/biosutils_1_00_02/packages;/opt/bios_5_31_08/packages;/opt/xdc_3_00_02/packages;/opt/xdc_3_00_02/packages;..;'. gmake: *** [package/cfg/ceapp_x470MV.c] Error 1 gmake: *** Deleting file `package/cfg/ceapp_x470MV.c' gmake: *** [package/cfg/ceapp_x470MV.c] Deleting file `package/cfg/ceapp_x470MV.xdl' gmake: *** [package/cfg/ceapp_x470MV.c] Deleting file `package/cfg/ceapp_x470MV.h' js: /opt/xdc_3_00_02/packages/xdc/tools/Cmdr.xs, line 40: Error: xdc.tools.configuro: configuration failed due to earlier errors (status = 2); 'linker.cmd' deleted. make[3]: *** [ceapp] Error 1 --- i found this lib decode_slice.a470MV generated in another place other than mentioned paths and i copied this lib to the above searched paths but it also fail and i do not thing this is right way to fix above error any help is highly appreciated --- --- Mohamed AbdElwahed Ibrahim [http://graphics.hotmail.com/i.p.emthup.gif] See all the ways you can stay connected to friends and familyhttp://www.microsoft.com/windows/windowslive/default.aspx ___ 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] ARM: DaVinci - Fix warnings from incorrect definition of at24_setup
Mark A. Greer mgr...@mvista.com writes:
From: Mark A. Greer mgr...@mvista.com
Fix the definitions of at24_setup() in two davinci board files
that are incorrect.
Signed-off-by: Mark A. Greer mgr...@mvista.com
Thanks, pushing.
Kevin
---
arch/arm/mach-davinci/board-dm644x-evm.c |4 +---
arch/arm/mach-davinci/board-dm646x-evm.c |3 +--
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index 5aeb085..384ad69 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -415,7 +415,7 @@ static struct pcf857x_platform_data pcf_data_u35 = {
*/
static struct memory_accessor *at24_mem_acc;
-static int at24_setup(struct memory_accessor *mem_acc, void *context)
+static void at24_setup(struct memory_accessor *mem_acc, void *context)
{
DECLARE_MAC_BUF(mac_str);
char mac_addr[6];
@@ -429,8 +429,6 @@ static int at24_setup(struct memory_accessor *mem_acc,
void *context)
memcpy(dm644x_evm_emac_pdata.mac_addr, mac_addr, 6);
}
-
- return 0;
}
static struct at24_platform_data eeprom_info = {
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index bcf11d5..5dd3006 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -64,7 +64,7 @@ static struct davinci_uart_config uart_config __initdata = {
*/
static struct memory_accessor *at24_mem_acc;
-static int at24_setup(struct memory_accessor *mem_acc, void *context)
+static void at24_setup(struct memory_accessor *mem_acc, void *context)
{
DECLARE_MAC_BUF(mac_str);
char mac_addr[6];
@@ -78,7 +78,6 @@ static int at24_setup(struct memory_accessor *mem_acc, void
*context)
memcpy(dm646x_evm_emac_pdata.mac_addr, mac_addr, 6);
}
- return 0;
}
static struct at24_platform_data eeprom_info = {
.byte_len = (256*1024) / 8,
--
1.6.0.3
___
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] ARM: DaVinci: EMAC: Fix alignment traps on packet reception
Isn't the issue that NET_IP_ALIGN is supposed to resolve, when properly used by network drivers? Looking at the documentation for that macro, drivers are supposed to call skb_reserve() with NET_IP_ALIGN as argument. The patch is doing the same, just not using the macro NET_IP_ALIGN. Maybe I will define the EMAC_L3_ALIGN macro as #define EMAC_L3_ALIGN(size)((NET_IP_ALIGN - (size)) 0x3) to be more clear? I'm actually wondering why the EMAC_L3_ALIGN macro is needed at all. Doesn't NET_IP_ALIGN -- used correctly -- resolve the issue completely? See how other drivers are doing it. You're allocating an skb, and reserving some extra space at the beginning. The normal procedure is more or less to reserve NET_IP_ALIGN bytes, to achieve proper alignment. ___ 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] ARM: DaVinci: Emac: Fix edma_alloc_channel when any channel requested
Troy Kisky troy.ki...@boundarydevices.com writes:
Before this, if a noevent channel was in use, the code
would go into an infinite loop.
Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
Thanks, pushing.
Kevin
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
index 9427c80..1f58631 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/mach-davinci/dma.c
@@ -492,6 +492,7 @@ int edma_alloc_channel(int channel,
return -ENOMEM;
if (!test_and_set_bit(channel, edma_inuse))
break;
+ channel++;
}
} else if (channel = num_channels) {
return -EINVAL;
--
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
___
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] ARM: DaVinci: EMAC: Fix alignment traps on packet reception
nsek...@ti.com writes:
From: Steve Chen sc...@mvista.com
The skb data allocated for packet data received is 4 byte aligned.
Unfortunately, this causes non-32bit aligned accesses in IP stack because
the MAC header is non-word aligned (14 bytes).
The result can be observed by looking at /proc/cpu/alignment while the
device is over network.
This issue is resolved by using a 2-byte extra offset in the packet buffer.
A quick performance test over lab network using iperf on DM6446 EVM showed
an increase in bandwidth from 60Mbits/s to 70Mbits/s.
Signed-off-by: Steve Chen sc...@mvista.com
Signed-off-by: Sekhar Nori nsek...@ti.com
Nori,
What are the plans to submit this driver to netdev? I'd like to see
this driver submitted upstream and thes kinds of issues being sorted
out on the netdev list.
Also, I thought you were planning to use NET_IP_ALIGN?
Kevin
---
drivers/net/davinci_emac.c | 21 +
1 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 635e31f..471126a 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -349,6 +349,15 @@ static const char emac_version_string[] = TI DaVinci
EMAC Linux v6.0;
#define EMAC_DM646X_MAC_EOI_C0_RXEN (0x01)
#define EMAC_DM646X_MAC_EOI_C0_TXEN (0x02)
+/*
+ * L3 Alignment mechanism: The below given macro returns the number of
+ * bytes required to align the given size to a L3 frame 4 byte
+ * boundry. This is typically required to add 2 bytes to the ethernet
+ * frame start to make sure the IP header (L3) is aligned on a 4 byte
+ * boundry
+ */
+#define EMAC_L3_ALIGN(size)((2 - (size)) 0x3)
+
/** net_buf_obj: EMAC network bufferdata structure
*
* EMAC network buffer data structure
@@ -1560,7 +1569,8 @@ static void *emac_net_alloc_rx_buf(struct emac_priv
*priv, int buf_size,
/* set device pointer in skb and reserve space for extra bytes */
p_skb-dev = ndev;
- skb_reserve(p_skb, EMAC_DEF_EXTRA_RXBUF_SIZE);
+ skb_reserve(p_skb, EMAC_DEF_EXTRA_RXBUF_SIZE +
+ EMAC_L3_ALIGN(EMAC_DEF_EXTRA_RXBUF_SIZE));
*data_token = (void *) p_skb;
EMAC_CACHE_WRITEBACK_INVALIDATE((unsigned long)p_skb-data, buf_size);
return p_skb-data;
@@ -1990,8 +2000,9 @@ static int emac_rx_bdproc(struct emac_priv *priv, u32
ch, u32 budget,
(pkts_processed budget)) {
new_buffer = emac_net_alloc_rx_buf(priv,
- EMAC_DEF_MAX_FRAME_SIZE,
- new_buf_token, EMAC_DEF_RX_CH);
+ EMAC_DEF_MAX_FRAME_SIZE +
+ EMAC_L3_ALIGN(EMAC_DEF_EXTRA_RXBUF_SIZE),
+ new_buf_token, EMAC_DEF_RX_CH);
if (unlikely(NULL == new_buffer)) {
++rxch-out_of_rx_buffers;
goto end_emac_rx_bdproc;
@@ -2411,7 +2422,9 @@ static int emac_dev_open(struct net_device *ndev)
ndev-dev_addr[cnt] = priv-mac_addr[cnt];
/* Configuration items */
- priv-rx_buf_size = EMAC_DEF_MAX_FRAME_SIZE + EMAC_DEF_EXTRA_RXBUF_SIZE;
+ priv-rx_buf_size = EMAC_DEF_MAX_FRAME_SIZE +
+ EMAC_DEF_EXTRA_RXBUF_SIZE +
+ EMAC_L3_ALIGN(EMAC_DEF_EXTRA_RXBUF_SIZE);
/* Clear basic hardware */
for (ch = 0; ch EMAC_MAX_TXRX_CHANNELS; ch++) {
--
1.6.0.3
___
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 16/18] ARM: da830 - Add base DA830/OMAP-L137 SoC support
David Brownell davi...@pacbell.net writes: On Tuesday 07 April 2009, Mark A. Greer wrote: Its unfortunate that the hook name in the drivers ATM is clk_enable(). I really *do not understand* where you're coming from at all. I think what Mark is getting at is that it's unfortunate that the drivers only have a single hook to do device-specific stuff, and it's directly tied to clocks. We have run into this in OMAP as well for PM reasons and have been tossing around some ideas to have a device_enable(), device_idle() device_off() type of model instead of clk_enable/clk_disable. Inside these functions, not only clocks could be managed but also other power resources like regulators etc. and the saving of device conext may be handled here too in case the powerdomain is going into off mode. It's possible that some muxing for some devices would be handled here for runtime flexibility as well. How about this as a compromise: Until such a model exists, one could easily extend the current situation by using platform_data hooks. Add 'device_enable' and 'device_disable' hooks to the platform_data which can be created for some of these problematic drivers. Then, the drive does clk_enable(); if (pdata-device_enable) device_enable(); /* do work */ if (pdata-device_disable) device_disable(); clk_disable(); Eventually, when the clk enable/disable itself would be moved into the platform-specific enable/disable function when a modle is agreed upon down the road. Kevin ___ 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 16/18] ARM: da830 - Add base DA830/OMAP-L137 SoC support
On Fri, Apr 10, 2009 at 08:57:40PM +0400, Sergei Shtylyov wrote: Hello. Mark A. Greer wrote: An example with the da830 evm is nand nor flash. The board has both but only one can be used at a time. Mark, you're ovesimlifying the matter here too much: NAND and NOR flashes are on the User Interface daughterboard, along with LCD -- that naturally can or cannot be plugged in. Depending on the revision of the board, you either can't have on-board MMC working if the daughter board is plugged in, or only if you're using one of the flashes on it (there's a GPIO expander on that dougterboard controlling the multiplexing of several pins to LCD or flashes and additionally controlling multiplexing of the MMC pins on the later board revisions, so that you can have MMC with the daughter board plugged in -- at least when you don't need flashes. (Unfortunately, you need to setup that GPIO expander from kernel for the LCD/MMC to be used because by defalt it selects flashes.) David, Kevin, if you're already feeling confused by the gory details of this, that was part of my task of giving you a feel how hairy the pinmux issues can become with only one daugtherboard. :-) I prefer the device be registered for both No way. :-) They use the *same AEMIF pins*, so the pinmux conflicts between them just can *not* be detected, and so I had to resort to a choice selecting either kind of flash (or LCD). Ugh, forgot about that. Okay, bad example but I was only using it to make [what I thought was a simple] point. and the user pick which one he/she wants via CONFIG options. Otherwise, we need to add #ifdef CONFIG_driver's to the board code. 2) It detects and complains about pinmux contention and there is a lot of potential contention with the da830. No less so than with OMAP, or lots of other SoCs. Contention is rarely a problem given a clearly structured framework for board init ... like being able to rely on device registration to perform the pinmux. For the da830 evm, this means adding #ifdef CONFIG_driver to board code. Which would in no way prevent the pinmux conflicts as the user can always select mutually exclusive drivers! So unless you add more ugly #ifdef'ery to explicitly check for the incompatible driver configurations (mega igly -- and yet this is what we had for DM644x EVM with NAND/NOR flashes and IDE), you're still subject to pinmux conflicts. Yep. Mark -- ___ 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 16/18] ARM: da830 - Add base DA830/OMAP-L137 SoC support
On Wed, Apr 08, 2009 at 02:58:18PM -0700, David Brownell wrote:
On Tuesday 07 April 2009, Mark A. Greer wrote:
Its better than making a whole bunch of globals and a whole bunch of
platform_device_register() calls in every board file. That's
unnecessary code bloat. This routine (whatever we call it) makes it
simple for board code to register all of the devices it wants
registered and without a bazillion globals, etc.
You propose:
- variable length table of { device tag, device-specific data }
- pass that table to some init function
- platform_device_register() for e.g. peripherals on EMIF
I said instead:
- variable set of calls to setup_device(device-specific data)
- platform_device_register() for e.g. peripherals on EMIF
In that sense they're isomorphic, except that you're creating a new
type framework instead of using the standard C type framework. Your
new type framework precludes compile-time type checking (and doesn't
include a runtime replacement), thereby increasing the likelihood of
init-time errors. (Which are already way too common; better to use
approaches which *reduce* them.)
I see no code bloat; if anything, there's less because you would need
extra code to perform the actions implied by that table. The globals
are basically __init code.
Okay, I understand better now. Thanks.
TBH, we've probably spent way more bits on this than its worth.
I think I'll remove da830_register_devices() (and enums), make the
da830 standard platform_device data global, and use
platform_add_devices() in the board code to add them (or just a bunch
of platform_device_register() calls).
I think I gave the example of SPI already. The platform_data should
not cover pinmuxing,
I never suggested using platform_data for pinmuxing.
You didn't provide an alternate location for it ... you only
passed platform_data. Ergo, to the extent you were making a
complete proposal, you certainly implied that's where it would
be going. (The issue in this case being which pinmux *options*
were needed ... like, which chipselects the board uses.)
You're trying to use an implementation problem (that's easily solved) to
justify doing pinmux setup at the wrong time/place.
I think that's what *you* are doing. Pinmux should be set
up before the device node is created. It's a separate problem
from clk_enable() ... even for cases like CLKOUTx pins.
You misunderstand me. I hope my other email straightens that out.
Moreover, you keep touching on the notion of detecting pinmux
conflicts at runtime, but haven't actually solved that problem.
That's easy with a little extra data support code in mach-davinci.
Until you solve it for real -- with a database of all pins, and
other resources, controlled by the DaVinci mux registers, and
which ones are affected by each mux setting; and a way to keep
growing that for each new SoC -- you should just remove arguments
presuming such a solution from your slate.
Okay, it seems like a patch is necessary at this point.
We don't seem to be able to communicate any other way.
That makes the most sense, that's what works the best (you can use
modules with conflicting resources as long as you don't have both
running at the same time), and that's the Linux model.
See above. Lacking any runtime solution to pinmux conflict
resolution, it's not particularly fair to premise your own
arguments on the existince of such a solution, is it??
Its unfortunate that the hook name in the drivers ATM is clk_enable().
I really *do not understand* where you're coming from at all.
It's called clk_enable() because -- wait for it!! -- its job
is to -- here it is!! -- enable the clock!! Surprised??
Nice...
Mark
--
___
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 16/18] ARM: da830 - Add base DA830/OMAP-L137 SoC support
On Wed, Apr 08, 2009 at 02:30:52PM -0700, David Brownell wrote: On Tuesday 07 April 2009, Mark A. Greer wrote: Maybe this will help. Its just a hack for your dm355 spi example try to get my point across. It uses lspc as the tag for what the device is but the clk struct could be extended to add a field for the pinmux. davinci_pinmux_alloc() basically does a davinci_cfg_reg() on every pin in dm355_pins[DAVINCI_LPSC_SPI] while making sure each pin has not already been allocated. Doesn't really help: - You're still coupling clocks to pinmux. Just don't. - The pin has not been allocated stuff isn't actually managing pins/balls ... I see nothing there that could record how for example which balls a cfg_reg setting can affect (it's not one pin per setting). - Doesn't even look particularly better in terms of how the SPI setup is used. Each board's setup code gets more complicated, not less. Well, I see my example failed to accomplish its goal. The goal wasn't to provide a complete solution, it was to show that board code can easily override the soc default setup. I used the dm355 spi example because that's that one you've referrd to several times. It would look better with a better example with lots of pins that need to be setup but only a few that need to be changed by board code. Mark -- ___ 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 16/18] ARM: da830 - Add base DA830/OMAP-L137 SoC support
On Mon, Apr 13, 2009 at 10:58:11AM -0700, Kevin Hilman wrote: David Brownell davi...@pacbell.net writes: On Tuesday 07 April 2009, Mark A. Greer wrote: Its unfortunate that the hook name in the drivers ATM is clk_enable(). I really *do not understand* where you're coming from at all. I think what Mark is getting at is that it's unfortunate that the drivers only have a single hook to do device-specific stuff, and it's directly tied to clocks. Kevin, thank you _so_ much. We have run into this in OMAP as well for PM reasons and have been tossing around some ideas to have a device_enable(), device_idle() device_off() type of model instead of clk_enable/clk_disable. Inside these functions, not only clocks could be managed but also other power resources like regulators etc. and the saving of device conext may be handled here too in case the powerdomain is going into off mode. Yeah, a rework of the kernel/driver API is what's really needed but that's no small chore. It's possible that some muxing for some devices would be handled here for runtime flexibility as well. How about this as a compromise: Until such a model exists, one could easily extend the current situation by using platform_data hooks. Add 'device_enable' and 'device_disable' hooks to the platform_data which can be created for some of these problematic drivers. Then, the drive does clk_enable(); if (pdata-device_enable) device_enable(); /* do work */ if (pdata-device_disable) device_disable(); clk_disable(); Eventually, when the clk enable/disable itself would be moved into the platform-specific enable/disable function when a modle is agreed upon down the road. Yes, this is a better solution than overloading clk_enable() IMHO but it, unfortunately, requires hacking a bunch of drivers. I have no problem doing that as long as there's a reasonable chance the upstream folks will accept that need for this. Mark -- ___ 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 16/18] ARM: da830 - Add base DA830/OMAP-L137 SoC support
On Wed, Apr 08, 2009 at 02:07:24PM -0700, David Brownell wrote: [ this is the followup re points I didn't address first time ] On Monday 06 April 2009, Mark A. Greer wrote: On Tue, Mar 31, 2009 at 07:19:13PM -0700, David Brownell wrote: ... Without coupling pinmux with the other two, which, as I've noted, doesn't work in general. (And also that the other two are really just one now: clock setup.) then we have to add explicit calls to set up the pinmux in either: a) The board code where you risk creating pinmux conflicts with devices that will never be enabled or else you have to add conditional logic based on Kconfig options. What ... you mean that when the hardware designers punt their conflict resolution to the software team, the conflicts don't just vanish? :) :) That's always going to be an ugly case. I've seen it with some development boards; it saves some costs since one board can be used for multiple purposes. Use cases for production hardware tend to be sequential ... e.g. dm6446 may boot from some flash on EMIF, but then uses IDE exclusively. I'd agree that production hardware tends to avoid resource conflicts but they do exist in real life systems. Either way, my real issue is higher level but more on that below. I tend to be content to have Kconfig expose such messes. Hmm, sounds like a bunch of 'depends on this !that ...' in Kconfig files which could get messy. When there are a bunch of config jumpers on the board, software is mostly unable to detect the actual hardware config. When the board stacks can be re-configured, and boards have no runtime identification scheme (like EEPROMs with board info), there's not a lot of choice. There may also be an option of some kind of board-specific dynamic configuation. Like a write-once debugfs file, default nothing is configured but you could write it to cause some devices to be set up: muxing, platform_device registration, and so on. (Equivalently: a kernel command line option, which may be important for devices holding the root fs.) That's interesting. Sysfs instead of debugfs, though? b) The drivers. This means we'll just add a call to set up the pinmux immediately after every clk_enable() call. I hope this isn't the plan. I thought there was pretty much a consensus that drivers should never be directly involved in pinmux. Among other things, it's rare that those details stay the same between different revisions of a given SoC. What you said was that platform_data should not cover pinmuxing and I agreed. Nothing about the pinmux should be made known to the driver. What the driver does know and needs to tell the board code is that it needs device 'X' enabled _now_ and tells the board code to go do whatever has to be done to enable it. It just so happens that we know that means doing something to the pinmux. It could mean any number of other things. There do seem to be a few *rare* special cases where pins need to switch modes ... e.g. to GPIO and back, briefly. One way to handle them is with callbacks provided in the platform_data. (Let me emphasise: *RARE* cases. As in, most developers never need to do this, never see it needed.) Switching back forth during use, yeah, I agree that's rare and a platform_data callback seems like a reasonable solution to me. its really nice to have it done automatically (and not having a hundred davinci_cfg_reg() calls in every board file). The cleanest way is IMO to have it set up when the device is registered. The device registration code can know e.g. that when the platform data says MMC has eight pins, it had better mux all eight pins. (If there are mux options, like DAT4 coming out on one of several pins, it can be told which option that board uses.) The same could be said for enabling the clock and psc too. No; clocks should be disabled unless they're needed. Like devices should be powered down unless they're needed. Sure, just like other resources for a device shouldn't be allocated/enabled until they're needed. I'm not sure what you mean by continuing to talk about PSC as if it's a separate thing from the clock. There are three things a PSC (Power and Sleep Controller) handles: - Module clocking. Exposed cleanly via linux/clk.h calls; this is currently the *primary* use of PSC. - Module resets. Linux doesn't have a generic reset hook; maybe DaVinci could provide one, but it's not yet been needed. - Module power on/off. Not that I've seen DaVinci chips where this actually functions! But I'd think that the linux/regulator.h framework would handle this. In short, today PSC is all about the clocks. Its because we are debating the issues at different levels. TI's PSCs clocks may be one and the same but the next company's may not be. The problem is we don't know what the user actually
Re: [PATCH 16/18] ARM: da830 - Add base DA830/OMAP-L137 SoC support
On Monday 13 April 2009, Kevin Hilman wrote: David Brownell davi...@pacbell.net writes: On Tuesday 07 April 2009, Mark A. Greer wrote: Its unfortunate that the hook name in the drivers ATM is clk_enable(). I really *do not understand* where you're coming from at all. I think what Mark is getting at is that it's unfortunate that the drivers only have a single hook to do device-specific stuff, and it's directly tied to clocks. I'd say that differently: they have few post-init hooks for anything except clock-specific stuff. And for that matter, most drivers leave clocks on all the time too... And when all you have is a hammer, everything starts to look like a nail! We have run into this in OMAP as well for PM reasons and have been tossing around some ideas to have a device_enable(), device_idle() device_off() type of model instead of clk_enable/clk_disable. Inside these functions, not only clocks could be managed but also other power resources like regulators etc. and the saving of device conext may be handled here too in case the powerdomain is going into off mode. That gets into interesting territory, since it expects devices fit into certain boxes ... enabled, idle, off for example. It's not uncommon for devices to have a hard time fitting into such small boxes: parts of them might be in one state, others might be in another one. It may be possible to analyse things so each part fits into such a box ... but not the whole device. If a device is a pure slave to the CPU, the models are likely to be simple: it can be in some low power mode -- maybe even completely off! -- whenever it's not being used. But when there is some ongoing responsibility in terms of external communications, there can be lots of nuances to what enabled or maybe idle means: active enough to be able to respond before a deadline, which may constraint a few other devices too. With USB, hosts can be suspended but with remote wakeup capability active: the differential D+/D- signal changes state. (This oddly seems to need a multi-MHz clock on most systems.) Ethernet links need to receive packets; etc. It's possible that some muxing for some devices would be handled here for runtime flexibility as well. Including off-mode handling for the balls, I could imagine. How about this as a compromise: Until such a model exists, one could easily extend the current situation by using platform_data hooks. Add 'device_enable' and 'device_disable' hooks to the platform_data which can be created for some of these problematic drivers. Experimenting with models is important ... it's hard to see what works, otherwise! :) That could be a good way to start. In terms of Mark's issues, those hooks would be where runtime resource conflicts would get resolved, like re-muxing. Then, the drive does clk_enable(); if (pdata-device_enable) device_enable(); This still seems to couple clocks and devices though. If there are multiple clocks, maybe they aren't all needed for the current bit of work. And maybe only a subset of other resources are needed too. Or to generalize ... there are lots of resources, and the ones that need to be activated are task-specific. - Dave /* do work */ if (pdata-device_disable) device_disable(); clk_disable(); Eventually, when the clk enable/disable itself would be moved into the platform-specific enable/disable function when a modle is agreed upon down the road. Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Codec Engine DSP_ETIMEOUT When loading DSP
I would suggest hooking up CCS and looking at what's going on with the DSP when
this happens. The DSP server needs to get to a handshake point with the ARM,
and it appears that the ARM is timing out after not receiving a response from
the DSP (error code DSP_EBASE + 0x17 is a timeout error).
Perhaps you need to use a different power control option in CE, or use the LPM
power manager from CE to turn on the DSP before running the ARM app.
Also, make sure you're using a recent CE/DSPLink combo that supports the 2.6.28
kernel.
- Rob
From: davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com
[mailto:davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com] On
Behalf Of Jeremy Larsen
Sent: Friday, April 10, 2009 2:08 PM
To: davinci-linux-open-source
Subject: Codec Engine DSP_ETIMEOUT When loading DSP
I am using a DM6446 on a custom board and with a custom 2.6.28 Kernel and
trying to get Codec Engine working.
I have reconfigured the memory map for 64MB of RAM.
To change the memory map I have followed the directions found here
http://focus.ti.com/lit/an/spraaq6/spraaq6.pdf
I can succesfully run DSPLINK and CMEM examples.
When I try to run the video_copy (or any other) example in codec engine I get
the following:
@0x00046b00:[T:0x4001cf40] OG - Global_atexit enter (fxn=0xad74)
@0x00046ca4:[T:0x4001cf40] OM - Memory_alloc Enter(0x18)
@0x00046dfd:[T:0x4001cf40] OM - Memory_alloc return (0x43890)
@0x000474a1:[T:0x4001cf40] OG - Global_atexit enter (fxn=0x1790c)
@0x000475e3:[T:0x4001cf40] OM - Memory_alloc Enter(0x18)
@0x0004768b:[T:0x4001cf40] OM - Memory_alloc return (0x438e0)
@0x00047712:[T:0x4001cf40] OG - Global_atexit enter (fxn=0x167b8)
@0x00047808:[T:0x4001cf40] OG - Global_atexit enter (fxn=0x19040)
@0x00047918:[T:0x4001cf40] ti.sdo.ce.osal.Sem - Sem_create count: 0
@0x000479b0:[T:0x4001cf40] OM - Memory_alloc Enter(0x14)
@0x00047a36:[T:0x4001cf40] OM - Memory_alloc return (0x43960)
@0x00047ad8:[T:0x4001cf40] ti.sdo.ce.osal.Sem - Leaving Sem_create sem[0x43960]
@0x00047b61:[T:0x4001cf40] ti.sdo.ce.osal.Sem - Sem_create count: 0
@0x00047bd6:[T:0x4001cf40] OM - Memory_alloc Enter(0x14)
@0x00047c4f:[T:0x4001cf40] OM - Memory_alloc return (0x43978)
@0x00047cc5:[T:0x4001cf40] ti.sdo.ce.osal.Sem - Leaving Sem_create sem[0x43978]
@0x00047d37:[T:0x4001cf40] OM - Memory_alloc Enter(0x18)
@0x00047db1:[T:0x4001cf40] OM - Memory_alloc return (0x43990)
@0x00047e2b:[T:0x4001cf40] OT - Thread_create Enter (fxn=0x14f90, attrs=0x0)
@0x00047ea2:[T:0x4001cf40] OM - Memory_alloc Enter(0x64)
@0x00047f1f:[T:0x4001cf40] OM - Memory_alloc return (0x439b0)
@0x000482dd:[T:0x40960490] OP - daemon thread created.
@0x000483d3:[T:0x40960490] OP - getCmd_d Enter (proc=0x4095fde0)
@0x00048470:[T:0x40960490] ti.sdo.ce.osal.Sem - Entered Sem_pend sem[0x43960]
timeout[0x]
@0x00048568:[T:0x4001cf40] OT - Thread_create Exit (task=0x439b0)
@0x0004860e:[T:0x4001cf40] OG - Global_atexit enter (fxn=0x14980)
@0x000486b2:[T:0x4001cf40] OG - Global_atexit enter (fxn=0x16d04)
@0x000487a0:[T:0x4001cf40] ti.sdo.ce.alg - ALG_init Enter
@0x0004882f:[T:0x4001cf40] OG - Global_atexit enter (fxn=0x145cc)
@0x000488b9:[T:0x4001cf40] ti.sdo.ce.alg - ALG_init Exit
@0x0004892c:[T:0x4001cf40] OG - Global_atexit enter (fxn=0x139f8)
@0x000489bf:[T:0x4001cf40] OM - Memory_alloc Enter(0x18)
@0x00048a48:[T:0x4001cf40] OM - Memory_alloc return (0x43b90)
@0x00048acb:[T:0x4001cf40] OG - Global_atexit enter (fxn=0x19530)
@0x00048bc8:[T:0x4001cf40] OG - Global_atexit enter (fxn=0x10e8c)
@0x00048c6a:[T:0x4001cf40] OM - Memory_alloc Enter(0x18)
@0x00048cf4:[T:0x4001cf40] OM - Memory_alloc return (0x43bf0)
@0x00048d7a:[T:0x4001cf40] OM - Memory_alloc Enter(0x18)
@0x00048dfb:[T:0x4001cf40] OM - Memory_alloc return (0x43c10)
@0x00048e75:[T:0x4001cf40] OM - Memory_alloc Enter(0x18)
@0x00048ef3:[T:0x4001cf40] OM - Memory_alloc return (0x43c30)
@0x00048fd2:[T:0x4001cf40] CS - Server_init()
@0x0004905a:[T:0x4001cf40] CS - Server_init Global_useLinkArbiter = 0
@0x000490dd:[T:0x4001cf40] OG - Global_atexit enter (fxn=0xf16c)
@0x000494bb:[T:0x4001cf40] OG - Global_atexit enter (fxn=0xcb90)
@0x000495e8:[T:0x4001cf40] CE - Engine_open Enter('video_copy', 0x0,
0xbecb8bf4)
@0x00049691:[T:0x4001cf40] OM - Memory_alloc Enter(0x2c)
@0x0004971f:[T:0x4001cf40] OM - Memory_alloc return (0x43cb0)
@0x000497a0:[T:0x4001cf40] CE - rserverOpen('video_copy.x64P'), count = 0
@0x00049821:[T:0x4001cf40] OP - Processor_create
Enter(imageName='video_copy.x64P', linkCfg='(null)', attrs=0xbecb8bd8)
@0x00049c98:[T:0x4001cf40] OM - Memory_alloc Enter(0x24)
@0x00049d67:[T:0x4001cf40] OM - Memory_alloc return (0x43ce0)
@0x00049dfb:[T:0x4001cf40] OP - doCmd Enter (cmdId=1, proc=0x43ce0)
@0x00049e83:[T:0x4001cf40] ti.sdo.ce.osal.Sem - Entered Sem_post sem[0x43960]
@0x00049f7b:[T:0x40960490] ti.sdo.ce.osal.Sem - Leaving Sem_pend sem[0x43960]
status[0]
@0x0004a038:[T:0x40960490] OP - getCmd_d Exit (result=1)
Re: [PATCH 0/18 v2] Add da830/omap-l137 support
Mark A. Greer mgr...@mvista.com writes: Round 2. I believe I have addressed all of the issues that I agreed to address. Every patch has checkpatch.pl's cleanly, builds cleanly, and has been tested on a dm355 evm, dm6446 evm, and dm6467 evm. The last patch was also tested on a da830 evm. This series assumes that the following patches have been added: http://linux.omap.com/pipermail/davinci-linux-open-source/2009-March/012097.htmlhttp://linux.omap.com/pipermail/davinci-linux-open-source/2009-April/012389.html Using the commit below[1] as the starting point and applying the two patches you reference above, this series doesn't fully apply. git am fails to apply patch 11, but forcing it makes it apply with fuzz, suggesting we have a slightly different base. Next, patch 13 fails to apply even after forcing due to conflicts in the at24 setup. I tried with and without the at24 patch you reference above and it fails in both cases. What's the base commit id of the tree you're using, before the two commits you link to above? Kevin [1] commit 8a16ff458a27764d72647c4a0b57f5ec82135f88 Author: Kevin Hilman khil...@deeprootsystems.com Date: Thu Mar 5 11:18:20 2009 -0800 davinci: eeprom: use new memory accessor interface Signed-off-by: Kevin Hilman khil...@deeprootsystems.com ___ 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 1/18 v2] ARM: DaVinci - Encapsulate SoC-specific data in a structure
Mark A. Greer mgr...@mvista.com writes:
From: Mark A. Greer mgr...@mvista.com
Create a structure to encapsulate SoC-specific information.
This will assist in generalizing code so it can be used by
different SoCs that have similar hardware but with minor
differences such as having a different base address.
The idea is that the code for each SoC fills out a structure
with the correct information. The board-specific code can
then modify anything in that structure before calling a
common init routine that makes a copy of the structure,
maps in I/O regions, etc. Code can get a pointer to the
structure by calling davinci_get_soc_info(). Eventually,
the common init routine will make a copy of all of the data
pointed to by the structure so the original data can be made
__init_data. That way the data for SoC's that aren't being
used won't occupy space for the entire life of the kernel.
The structure will be extended in subsequent patches but
initially, it holds the map_desc structure for any I/O
regions the SoC/board wants statically mapped.
Signed-off-by: Mark A. Greer mgr...@mvista.com
[...]
#define DAVINCI_ASYNC_EMIF_CONTROL_BASE 0x01e1
#define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE 0x0200
@@ -189,8 +190,13 @@ static struct davinci_uart_config uart_config __initdata
= {
static void __init dm355_evm_map_io(void)
{
- davinci_map_common_io();
- dm355_init();
+ int ret;
+
+ ret = davinci_common_init(davinci_soc_info_dm355);
+ if (ret)
+ pr_err(SoC Initialization failed\n);
+ else
+ dm355_init();
Hmm... you reworked this due to my suggestion, but I still don't quite
like this.
Seems like you've had to make davinci_soc_info_soc global only so
that it can be passed into common_init() from the board files. Instead,
how about just keep the call to dm355_init(), and then, in dm355.c, call
common_init() with the soc_info struct statically defined there.
This keeps the SoC info struct local to the SoC specific file, and all
the board file has to know at this early init phase is which SoC it's
using.
Kevin
___
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 1/18 v2] ARM: DaVinci - Encapsulate SoC-specific data in a structure
On Mon, Apr 13, 2009 at 02:30:49PM -0700, Kevin Hilman wrote:
Mark A. Greer mgr...@mvista.com writes:
#define DAVINCI_ASYNC_EMIF_CONTROL_BASE0x01e1
#define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE 0x0200
@@ -189,8 +190,13 @@ static struct davinci_uart_config uart_config
__initdata = {
static void __init dm355_evm_map_io(void)
{
- davinci_map_common_io();
- dm355_init();
+ int ret;
+
+ ret = davinci_common_init(davinci_soc_info_dm355);
+ if (ret)
+ pr_err(SoC Initialization failed\n);
+ else
+ dm355_init();
Hmm... you reworked this due to my suggestion, but I still don't quite
like this.
Seems like you've had to make davinci_soc_info_soc global only so
that it can be passed into common_init() from the board files. Instead,
how about just keep the call to dm355_init(), and then, in dm355.c, call
common_init() with the soc_info struct statically defined there.
This keeps the SoC info struct local to the SoC specific file, and all
the board file has to know at this early init phase is which SoC it's
using.
Yeah, it does look silly, doesn't it :-/
I'll implment what you suggest.
Mark
--
___
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/18 v2] Add da830/omap-l137 support
On Mon, Apr 13, 2009 at 02:18:02PM -0700, Kevin Hilman wrote: Mark A. Greer mgr...@mvista.com writes: Round 2. I believe I have addressed all of the issues that I agreed to address. Every patch has checkpatch.pl's cleanly, builds cleanly, and has been tested on a dm355 evm, dm6446 evm, and dm6467 evm. The last patch was also tested on a da830 evm. This series assumes that the following patches have been added: http://linux.omap.com/pipermail/davinci-linux-open-source/2009-March/012097.htmlhttp://linux.omap.com/pipermail/davinci-linux-open-source/2009-April/012389.html Using the commit below[1] as the starting point and applying the two patches you reference above, this series doesn't fully apply. git am fails to apply patch 11, but forcing it makes it apply with fuzz, suggesting we have a slightly different base. Next, patch 13 fails to apply even after forcing due to conflicts in the at24 setup. I tried with and without the at24 patch you reference above and it fails in both cases. What's the base commit id of the tree you're using, before the two commits you link to above? Kevin [1] commit 8a16ff458a27764d72647c4a0b57f5ec82135f88 Author: Kevin Hilman khil...@deeprootsystems.com Date: Thu Mar 5 11:18:20 2009 -0800 davinci: eeprom: use new memory accessor interface Signed-off-by: Kevin Hilman khil...@deeprootsystems.com Hmm... They are based on 8a16ff458a27764d72647c4a0b57f5ec82135f88. I must have resolved some conflicts in the other patches locally forgot. I'll forward them to you in a minute. Mark -- ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] ARM: DaVinci - Fix warnings from incorrect definition of at24_setup
From: Mark A. Greer mgr...@mvista.com
Fix the definitions of at24_setup() in two davinci board files
that are incorrect.
Signed-off-by: Mark A. Greer mgr...@mvista.com
---
arch/arm/mach-davinci/board-dm644x-evm.c |4 +---
arch/arm/mach-davinci/board-dm646x-evm.c |3 +--
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index 5aeb085..384ad69 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -415,7 +415,7 @@ static struct pcf857x_platform_data pcf_data_u35 = {
*/
static struct memory_accessor *at24_mem_acc;
-static int at24_setup(struct memory_accessor *mem_acc, void *context)
+static void at24_setup(struct memory_accessor *mem_acc, void *context)
{
DECLARE_MAC_BUF(mac_str);
char mac_addr[6];
@@ -429,8 +429,6 @@ static int at24_setup(struct memory_accessor *mem_acc, void
*context)
memcpy(dm644x_evm_emac_pdata.mac_addr, mac_addr, 6);
}
-
- return 0;
}
static struct at24_platform_data eeprom_info = {
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index bcf11d5..5dd3006 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -64,7 +64,7 @@ static struct davinci_uart_config uart_config __initdata = {
*/
static struct memory_accessor *at24_mem_acc;
-static int at24_setup(struct memory_accessor *mem_acc, void *context)
+static void at24_setup(struct memory_accessor *mem_acc, void *context)
{
DECLARE_MAC_BUF(mac_str);
char mac_addr[6];
@@ -78,7 +78,6 @@ static int at24_setup(struct memory_accessor *mem_acc, void
*context)
memcpy(dm646x_evm_emac_pdata.mac_addr, mac_addr, 6);
}
- return 0;
}
static struct at24_platform_data eeprom_info = {
.byte_len = (256*1024) / 8,
--
1.6.0.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] ARM: Add writethrough dcache support for ARM926EJS processor
From: Mark A. Greer mgr...@mvista.com The ARM kernel supports writethrough data cache via the CONFIG_CPU_DCACHE_WRITETHROUGH option. However, that functionality wasn't implemented in the arch/arm/boot/compressed code. It is now necessary due to a new ARM926EJS processor that has an issue with writeback data cache. Signed-off-by: Mark A. Greer mgr...@mvista.com --- arch/arm/boot/compressed/head.S | 15 +++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index 77d6142..250be13 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -399,7 +399,11 @@ __setup_mmu: sub r3, r4, #16384 @ Page directory size orr r1, r1, #3 10 add r2, r3, #16384 1: cmp r1, r9 @ if virt start of RAM +#ifdef CONFIG_CPU_DCACHE_WRITETHROUGH + orrhs r1, r1, #0x08 @ set cacheable +#else orrhs r1, r1, #0x0c @ set cacheable, bufferable +#endif cmp r1, r10 @ if virt end of RAM bichs r1, r1, #0x0c @ clear cacheable, bufferable str r1, [r0], #4@ 1:1 mapping @@ -423,6 +427,11 @@ __setup_mmu: sub r3, r4, #16384 @ Page directory size mov pc, lr ENDPROC(__setup_mmu) +__arm926ejs_mmu_cache_on: +#ifdef CONFIG_CPU_DCACHE_WRITETHROUGH + mov r0, #4 @ put dcache in WT mode + mcr p15, 7, r0, c15, c0, 0 +#endif __armv4_mmu_cache_on: mov r12, lr bl __setup_mmu @@ -604,6 +613,12 @@ proc_types: b __armv4_mpu_cache_off b __armv4_mpu_cache_flush + .word 0x41069260 @ ARM926EJ-S (v5TEJ) + .word 0xff00 + b __arm926ejs_mmu_cache_on + b __armv4_mmu_cache_off + b __armv5tej_mmu_cache_flush + .word 0x7000 @ ARM7 IDs .word 0xf000 mov pc, lr -- 1.6.0.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] Do not re-enable EMAC interrupt if receive processing has usedits entire budget
Do not re-enable interrupts if receive processing has used its entire
budget.
As described in net/core/dev.c, function net_rx_action, drivers must not
modify
the NAPI state if they consume their entire weight. Davinci EMAC driver was
re-enabling interrupts in the rare case that it has used its budget, and
there
was now no more work to do.
Tested on DM644x EVM.
---
drivers/net/davinci_emac.c | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 89ff48b..b3017ef 100755
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -2157,7 +2157,8 @@ static int emac_poll(struct napi_struct *napi, int
budget)
struct emac_priv *priv = container_of(napi, struct emac_priv, napi);
struct net_device *ndev = priv-ndev;
u32 status = 0;
- u32 num_pkts = 0;
+ u32 num_txpkts = 0;
+ u32 num_rxpkts = 0;
u32 txpending = 0;
u32 rxpending = 0;
@@ -2173,7 +2174,7 @@ static int emac_poll(struct napi_struct *napi, int
budget)
mask = EMAC_DM646X_MAC_IN_VECTOR_TX_INT_VEC;
if (status mask) {
- num_pkts = emac_tx_bdproc(priv, EMAC_DEF_TX_CH,
+ num_txpkts = emac_tx_bdproc(priv, EMAC_DEF_TX_CH,
EMAC_DEF_TX_MAX_SERVICE,
txpending);
} /* TX processing */
@@ -2184,7 +2185,7 @@ static int emac_poll(struct napi_struct *napi, int
budget)
mask = EMAC_DM646X_MAC_IN_VECTOR_RX_INT_VEC;
if (status mask) {
- num_pkts = emac_rx_bdproc(priv, EMAC_DEF_RX_CH,
+ num_rxpkts = emac_rx_bdproc(priv, EMAC_DEF_RX_CH,
budget, rxpending);
} /* RX processing */
@@ -2194,8 +2195,10 @@ static int emac_poll(struct napi_struct *napi,
int budget)
__netif_rx_schedule(priv-napi);
}
} else {
- netif_rx_complete(napi);
- emac_int_enable(priv);
+ if (num_rxpkts != budget) {
+ netif_rx_complete(napi);
+ emac_int_enable(priv);
+ }
}
if (unlikely(status EMAC_DM644X_MAC_IN_VECTOR_HOST_INT)) {
@@ -2226,7 +2229,7 @@ static int emac_poll(struct napi_struct *napi, int
budget)
}
} /* Host error processing */
- return num_pkts;
+ return num_rxpkts;
}
--
1.5.6.3
===
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Reminder: Please Respond to Avik's Invitation
Avik Ghose wants you to join Yaari! Is Avik your friend? a href=http://yaari.com/?controller=useraction=mailregisterfriend=1sign=YaariDDL664IJJ621UMC925ADC422;Yes, Avik is my friend!/a a href=http://yaari.com/?controller=useraction=mailregisterfriend=0sign=YaariDDL664IJJ621UMC925ADC422;No, Avik isn't my friend./a Please respond or Avik may think you said no :( Thanks, The Yaari Team If you prefer not to receive this email tell us a href=http://yaari.com/?controller=absnaction=addoptoutemail=davinci-linux-open-sou...@linux.davincidsp.com;here/a. If you have any concerns regarding the content of this message, please email ab...@yaari.com. Yaari LLC, 358 Angier Ave, Atlanta, GA 30312 YaariDDL664IJJ621UMC925ADC422 ___ 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] Do not re-enable EMAC interrupt if receive processing hasused its entire budget
In response to a request, I have created a patch against kernel version
2.6.29-davinci1, using git-format-patch. This is similar code to that
patch that I submitted earlier, except this time for 2.6.29, rather than
2.6.27.
However, I still have some issues with this fix; it deserves a better look.
1. Other Ethernet drivers do not bother to mess around with the NAPI
list if they need to continue polling. Davinci EMAC driver could
probably copy this (eg e100 driver)
2. There is one case in the nested if-statements that does nothing. This
implies that the statement above it true, since the Davinci EMAC driver
sometimes 'does nothing'.
3. In emac_rx_bdproc() and emac_tx_bdproc(), when the pending flag is
set, it also checks whether it has consumed the entire budget. The code
could probably do with some rationalisation between emac_?x_bdproc()
functions, and emac_poll().
I have implemented a different patch that resolves 1. and 2. above.
However, I am not an expert on the Davinci EMAC hardware, or of Linux
device drivers in general, and do not feel qualified to review
emac_rx_bdproc() and emac_poll().
So I will submit my preferred patch, and leave the review of
emac_rx_bdproc() and emac_poll() to those better qualified.
Stephen Irons
Stephen Irons wrote:
Do not re-enable interrupts if receive processing has used its entire
budget.
As described in net/core/dev.c, function net_rx_action, drivers must
not modify
the NAPI state if they consume their entire weight. Davinci EMAC
driver was
re-enabling interrupts in the rare case that it has used its budget,
and there
was now no more work to do.
Tested on DM644x EVM.
---
drivers/net/davinci_emac.c | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 89ff48b..b3017ef 100755
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -2157,7 +2157,8 @@ static int emac_poll(struct napi_struct *napi,
int budget)
struct emac_priv *priv = container_of(napi, struct emac_priv,
napi);
struct net_device *ndev = priv-ndev;
u32 status = 0;
- u32 num_pkts = 0;
+ u32 num_txpkts = 0;
+ u32 num_rxpkts = 0;
u32 txpending = 0;
u32 rxpending = 0;
@@ -2173,7 +2174,7 @@ static int emac_poll(struct napi_struct *napi,
int budget)
mask = EMAC_DM646X_MAC_IN_VECTOR_TX_INT_VEC;
if (status mask) {
- num_pkts = emac_tx_bdproc(priv, EMAC_DEF_TX_CH,
+ num_txpkts = emac_tx_bdproc(priv, EMAC_DEF_TX_CH,
EMAC_DEF_TX_MAX_SERVICE,
txpending);
} /* TX processing */
@@ -2184,7 +2185,7 @@ static int emac_poll(struct napi_struct *napi,
int budget)
mask = EMAC_DM646X_MAC_IN_VECTOR_RX_INT_VEC;
if (status mask) {
- num_pkts = emac_rx_bdproc(priv, EMAC_DEF_RX_CH,
+ num_rxpkts = emac_rx_bdproc(priv, EMAC_DEF_RX_CH,
budget, rxpending);
} /* RX processing */
@@ -2194,8 +2195,10 @@ static int emac_poll(struct napi_struct *napi,
int budget)
__netif_rx_schedule(priv-napi);
}
} else {
- netif_rx_complete(napi);
- emac_int_enable(priv);
+ if (num_rxpkts != budget) {
+ netif_rx_complete(napi);
+ emac_int_enable(priv);
+ }
}
if (unlikely(status EMAC_DM644X_MAC_IN_VECTOR_HOST_INT)) {
@@ -2226,7 +2229,7 @@ static int emac_poll(struct napi_struct *napi,
int budget)
}
} /* Host error processing */
- return num_pkts;
+ return num_rxpkts;
}
--
1.5.6.3
===
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===
___
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/18 v2] Add da830/omap-l137 support
Mark A. Greer mgr...@mvista.com writes: On Mon, Apr 13, 2009 at 02:18:02PM -0700, Kevin Hilman wrote: Mark A. Greer mgr...@mvista.com writes: Round 2. I believe I have addressed all of the issues that I agreed to address. Every patch has checkpatch.pl's cleanly, builds cleanly, and has been tested on a dm355 evm, dm6446 evm, and dm6467 evm. The last patch was also tested on a da830 evm. This series assumes that the following patches have been added: http://linux.omap.com/pipermail/davinci-linux-open-source/2009-March/012097.htmlhttp://linux.omap.com/pipermail/davinci-linux-open-source/2009-April/012389.html Using the commit below[1] as the starting point and applying the two patches you reference above, this series doesn't fully apply. git am fails to apply patch 11, but forcing it makes it apply with fuzz, suggesting we have a slightly different base. Next, patch 13 fails to apply even after forcing due to conflicts in the at24 setup. I tried with and without the at24 patch you reference above and it fails in both cases. What's the base commit id of the tree you're using, before the two commits you link to above? Kevin [1] commit 8a16ff458a27764d72647c4a0b57f5ec82135f88 Author: Kevin Hilman khil...@deeprootsystems.com Date: Thu Mar 5 11:18:20 2009 -0800 davinci: eeprom: use new memory accessor interface Signed-off-by: Kevin Hilman khil...@deeprootsystems.com Hmm... They are based on 8a16ff458a27764d72647c4a0b57f5ec82135f88. OK, that's the same base I was using. I must have resolved some conflicts in the other patches locally forgot. I'll forward them to you in a minute. No change with the new versions of the writethrough and the at24 fixup patches just posted. Still fails on patch 11 and 13. Kevin ___ 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, I tried to test the linux-2.6.28-davinci1 (download from the http://source.mvista.com/git/) on my platform board. (my nand flash is NAND01GR3B2B: Manufacturer ID= 0x20,Device ID= 0xA1,Pages Per Block= 0x40.Number of Blocks= 0x400,Bytes Per Page= 0x800) and I found that the kernel scan nand flash rightly: = *davinci_nand davinci_nand.0: Warning: MUX config for NAND: Set PINMUX0 reg to 0x8000c01f, was 0x801f, should be done by bootloader. NAND device: Manufacturer ID: 0x20, Chip ID: 0xa1 (ST Micro NAND 128MiB 1,8V 8-bit) davinci_nand davinci_nand.0: Bad block scan: 0 out of 1024 blocks are bad. Creating 1 MTD partitions on davinci_nand.0: 0x00a0-0x0800 : NAND filesystem* = but when I test the MVL Pro V4.0(linux-2.6.10) on my board, the kernel treat all the blocks of my nand flash as bad: = *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 3 at 0x0006 Bad eraseblock 4 at 0x0008 Bad eraseblock 5 at 0x000a Bad eraseblock 6 at 0x000c Bad eraseblock 7 at 0x000e Bad eraseblock 8 at 0x0010 Bad eraseblock 9 at 0x0012 Bad eraseblock 10 at 0x0014 ……* *Bad eraseblock 1016 at 0x07f0 Bad eraseblock 1017 at 0x07f2 Bad eraseblock 1018 at 0x07f4 Bad eraseblock 1019 at 0x07f6 Bad eraseblock 1020 at 0x07f8 Bad eraseblock 1021 at 0x07fa Bad eraseblock 1022 at 0x07fc Bad eraseblock 1023 at 0x07fe* = So could you tell me how to update the nand driver from linux-2.6.10 (MVL Pro4.0) to linux-2.6.28-davinci1? Maybe I could use the linux-2.6.28-davinci1 directly, but the linux2.6.28-davinci1 net driver is not suit for my MAC chip(Broadcom BCM5221): == *.. davinci_init_emac: using random MAC addr: 2e:c0:34:3e:26:73 emac-mii: probed eth0: no PHY found IP-Config: Failed to open eth0 IP-Config: No network devices available. ...* === and I set the phy driver for my emac chip(Broadcom BCM5221)(use *make* * menuconfig* command): Device Drivers - Network Device Support - PHY Device support and infrastructure-Drivers for Broadcom PHYs and could you give me some suggestions to modified the source code of the net dirver of the linux-2.6.28-davinci1 for my MAC chip? Thank you! Zhang 2009/4/13 Philby John pj...@in.mvista.com 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
