dm355:ecc query
Hi, I am reading "sprufb3.pdf". I found following point on page 157. "Copy the User boot-loader from NAND flash to IRAM with hardware ECC error detection enabled. If a 4-bit ECC read error is detected, the UBL will correct the error via the ECC correction algorithm. If the read fails due to any other error, the descriptor search process begins anew in the next block after that in which the UBL descriptor was found for up to the first 24 blocks. If no valid UBL descriptor is found after searching 24 blocks, the RBL will try to boot via MMC/SD." Can anyone explain me what does this mean? Regards, Jitendra ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Resizer Initialization
Hi,
Instead of changing resizer driver, I would suggest to get the major number
from proc and create the node.
Thanks,
Brijesh Jadav
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
Yusuf Caglar AKYUZ
Sent: Thursday, January 22, 2009 9:32 PM
To: Steve Ressler
Cc: davinci-linux-open-sou...@linux.
Subject: Re: Resizer Initialization
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Steve Ressler wrote:
> Hi,
>
>>Are you sure that resizer takes major number 254? I guess it uses
>>dynamic number allocation.
>
>
> I believe you are correct, it uses dynamic number allocation. 254 was the
> number
> I saw it using when the device file was created by the init scripts. How can
> I
> find the correct major number? I'm not running the init scripts, so there is
> nothing in /proc to check.
>
> Maybe I should have asked: How can I use the resizer without running the init
> scripts?
>
AFAIK, you cannot check device numbers without proc or sysfs. Some
options coming to mind:
1)
Edit resizer driver drivers/char/davinci_resizer.c Change line:
result = alloc_chrdev_region(&dev, ZERO, 1, DRIVER_NAME);
to:
dev = MKDEV(254_or_some_number_unique_in_the_system, ZERO);
result = register_chrdev_region(dev, 1, DRIVER_NAME);
Don't forget to create node for the number you choose as major.
2)
Create a file in your filesystem and edit, let's say /home/my_init.sh:
#!/bin/sh
mount /proc
RES=$(cat /proc/devices | awk '/davinci_resizer/ {print $1}')
rm -f /dev/resizer
mknod /dev/resizer c $RES 0
/path/to/your/app/app
Then start this script as init, instead of your application.
3)
You can also edit your inittab. Instead of running init scripts you can
just mount some filesystems and then start your application.
I don't use MV fs and kernel, so I can't try these. But I guess they may
give some ideas.
Regards,
Caglar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iEYEARECAAYFAkl4mH4ACgkQ/nL+S5dojeht1QCfVRqG0HxB7zqUIs6c2l4QRhrC
/3YAoJb573wRtHKDi0ArFEqk83wrOKI5
=3nas
-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
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
I can't compile dm355 's demo
hi,Davinci-linux-open-source: when i compile the dm355's demo, i find this problem : the file of dm355_ipipe.h is not found ... thanks devin hdqst...@163.com 2009-01-23 BEGIN:VCARD VERSION:2.1 N:»Æ;µÂÇ¿ FN:»ÆµÂÇ¿ EMAIL;PREF;INTERNET:hdqst...@163.com REV:20090123T110915Z END:VCARD ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[RFT/PATCH] clock: rework PLL/clock handling, with goal of DVFS capable clock tree
Here's a another pass at better modeling of clocks and PLLs. The
longer term goal being the ability model the clock tree well enough to
do DVFS on parts that support it.
- generalize PLLs
- model PLLs, their dividers and the resulting SYSCLKs
- add concept of clock parents
- drop 'div_by_*' in favor of using PLL dividers
- misc. other minor cleanups
- move clock definitions into chip-specific code
- start using clk_get_rate() to get rates (UART, timers)
TODO:
- implement the programmable dividers
- seek-and-destroy hardcoded clock rates
Signed-off-by: Kevin Hilman
---
arch/arm/mach-davinci/board-dm355-evm.c |3 +-
arch/arm/mach-davinci/board-dm644x-evm.c|2 +-
arch/arm/mach-davinci/board-dm646x-evm.c|5 +-
arch/arm/mach-davinci/board-sffsdr.c|2 +-
arch/arm/mach-davinci/clock.c | 370 +++
arch/arm/mach-davinci/clock.h | 51 -
arch/arm/mach-davinci/dm355.c | 227
arch/arm/mach-davinci/dm644x.c | 195 ++
arch/arm/mach-davinci/dm646x.c | 154 +++
arch/arm/mach-davinci/include/mach/clock.h |2 +-
arch/arm/mach-davinci/include/mach/common.h |1 -
arch/arm/mach-davinci/include/mach/dm355.h | 18 ++
arch/arm/mach-davinci/include/mach/dm644x.h |2 +
arch/arm/mach-davinci/include/mach/dm646x.h | 18 ++
arch/arm/mach-davinci/io.c |6 -
arch/arm/mach-davinci/serial.c |6 +-
arch/arm/mach-davinci/time.c| 16 +-
17 files changed, 771 insertions(+), 307 deletions(-)
create mode 100644 arch/arm/mach-davinci/dm355.c
create mode 100644 arch/arm/mach-davinci/dm644x.c
create mode 100644 arch/arm/mach-davinci/dm646x.c
create mode 100644 arch/arm/mach-davinci/include/mach/dm355.h
create mode 100644 arch/arm/mach-davinci/include/mach/dm646x.h
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index d62d19a..1821d3d 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include
#include
@@ -177,6 +178,7 @@ static struct davinci_board_config_kernel
davinci_evm_config[] __initdata = {
static void __init dm355_evm_map_io(void)
{
davinci_map_common_io();
+ dm355_init();
}
static int dm355evm_mmc_get_cd(int module)
@@ -238,7 +240,6 @@ static __init void dm355_evm_init(void)
static __init void dm355_evm_irq_init(void)
{
- davinci_init_common_hw();
davinci_irq_init();
}
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index 359b754..113ae3b 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -594,6 +594,7 @@ static void __init
davinci_evm_map_io(void)
{
davinci_map_common_io();
+ dm644x_init();
}
static int davinci_phy_fixup(struct phy_device *phydev)
@@ -640,7 +641,6 @@ static __init void davinci_evm_init(void)
static __init void davinci_evm_irq_init(void)
{
- davinci_init_common_hw();
davinci_irq_init();
}
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index 6b1f323..8b7ef25 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -33,9 +33,10 @@
#include
#include
#include
+
+#include
#include
#include
-#include
#include
#include
#include
@@ -120,6 +121,7 @@ static void __init evm_init_i2c(void)
static void __init davinci_map_io(void)
{
davinci_map_common_io();
+ dm646x_init();
}
static __init void evm_init(void)
@@ -133,7 +135,6 @@ static __init void evm_init(void)
static __init void davinci_dm646x_evm_irq_init(void)
{
- davinci_init_common_hw();
davinci_irq_init();
}
diff --git a/arch/arm/mach-davinci/board-sffsdr.c
b/arch/arm/mach-davinci/board-sffsdr.c
index 9dab21d..e6db2e2 100644
--- a/arch/arm/mach-davinci/board-sffsdr.c
+++ b/arch/arm/mach-davinci/board-sffsdr.c
@@ -152,6 +152,7 @@ static struct davinci_board_config_kernel
davinci_sffsdr_config[] __initdata = {
static void __init davinci_sffsdr_map_io(void)
{
davinci_map_common_io();
+ dm644x_init();
}
static __init void davinci_sffsdr_init(void)
@@ -187,7 +188,6 @@ __setup("eth=", davinci_cpmac_eth_setup);
static __init void davinci_sffsdr_irq_init(void)
{
- davinci_init_common_hw();
davinci_irq_init();
}
diff --git a/arch/arm/mach-davinci/clock.c b/arch/arm/mach-davinci/clock.c
index 67ab35d..68a0fc9 100644
--- a/arch/arm/mach-davinci/clock.c
+++ b/arch/arm/mach-davinci/clock.c
@@ -25,22 +25,10 @@
#include
#include "clock.h"
-#define DAVINCI_PLL_CNTRL0_BASE 0x01C40800
-
-/* PLL/Reset register offsets */
-#define PLLM 0x110
-
static LIST_HEAD(clocks);
static DEFINE_MUTEX
Re: DM6446 MUSB
BTW, if DMA used, you should not cp data from one usb to another via dma. Such as file from one usb disk to another. Other usage is ok. On Jan 23, 2009, at 8:58 AM, davinci-linux-open-source-requ...@linux.davincidsp.com wrote: Send Davinci-linux-open-source mailing list submissions to davinci-linux-open-source@linux.davincidsp.com To subscribe or unsubscribe via the World Wide Web, visit http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open- source or, via email, send a message with subject or body 'help' to davinci-linux-open-source-requ...@linux.davincidsp.com You can reach the person managing the list at davinci-linux-open-source-ow...@linux.davincidsp.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Davinci-linux-open-source digest..." Today's Topics: 1. Re: omap-L1xxx (Kevin Hilman) 2. RE: omap-L1xxx (He, Zhengting) 3. RE: omap-L1xxx (He, Zhengting) 4. Re: DM6446 MUSB (Sergei Shtylyov) 5. Re: DM6446 MUSB (David Chan) -- Message: 1 Date: Thu, 22 Jan 2009 14:04:55 -0800 From: Kevin Hilman Subject: Re: omap-L1xxx To: "He, Zhengting" Cc: "davinci-linux-open-source@linux.davincidsp.com" , "Wells,Kimberly" , "McGoldrick, Bobby" , "Venkat, Subbu" , "Friedland, David" Message-ID: <87ljt380ag@deeprootsystems.com> Content-Type: text/plain; charset=shift_jis "He, Zhengting" writes: Hi, All, After some discussion internally in TI, I think we (as TI catalog) would like to change the proposal a little bit. 1. The macros and source code will have da830 only. (no change) 2. The menuconfig prompts will have "DA830/OMAP-L137" in them. (no change) 3. The defconfig would be called da830_omapl137_defconfig (no change). So far, so good. 4. The file and directory names should also have omapl137. (CHANGE) I have listed the following directory and file names which are required to be changed. (There are not many). With the file/directory name change, OMAPL137 users can tell which code is specifically applicable to OMAPL137 at a first glance. Does everyone agree this change? Personally, I think this is a bit cumbersome. I'm perfectly fine with the user-visible names and strings having both, but enforcing this type of naming into the kernel structure itself is overkill IMHO. Do you expect most users to be digging into the kernel at that level? If so, I would rather see this addressed in Documentation that comes with the product rather than having filenames carry the burden. My $0.02. Kevin / **/ /* Directory names to be changed */ / **/ include/config/mach/da8xx include/config/snd/da8xx arch/arm/mach-da8xx drivers/char/da8xx_lcd drivers/video/da8xx / **/ /* File names to be changed */ / **/ arch/arm/mach-da8xx/da8xx.h include/config/rtc/drv/da8xx.h drivers/usb/musb/da8xx.c drivers/video/da8xx/da8xx_fb.c drivers/video/da8xx/da8xx_fb.h drivers/video/da8xx/da8xx_lcdc.h Zhengting He (Ph.D) Application Engineer DSP Catalog email: z-...@ti.com voice: 281-274-4355 fax: 281-274-2279 -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Mark A. Greer Sent: 2009N122ú 11:54 To: Longley, Lester Cc: davinci-linux-open-source@linux.davincidsp.com; Wells, Kimberly; McGoldrick, Bobby Subject: Re: omap-L1xxx On Thu, Jan 22, 2009 at 09:53:43AM -0600, Longley, Lester wrote: Hi Mark, From: Mark A. Greer [mailto:mgr...@mvista.com] On Wed, Jan 21, 2009 at 11:35:07AM -0800, Kevin Hilman wrote: "Longley, Lester" writes: [ ... ] From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com] [ ... ] So, how should we reference to OMAP-L1x in kernel (in order to avoid the confusion with real OMAP)? It's the strong preference from my group, Performance Media, that "da830" be *included* in the name. Lester, thanks for sharing the views of your group. Do you mean included along with the omapl1x name? Or would your team be OK with only the da830 naming (which would be my preference)? For in-kernel code, I think it would be *really* clumsy to have both. In other words, I would much rather have #define DA830_MY_VAR void da830_my_func(void); OR #define OMAPL1X_MY_VAR void omapl1x_my_func(void); instead of: #define DA830_OMAPL1X_MY_VAR void da830_omapl1x_my_func(void); Which I think would be more confusing than informative. Maybe one could consider that a side benefit of such naming is
Re: DM6446 MUSB
Hi, Brian The DMA is supported by current git for dm6446 usb. I've used for quite a long period. David On Jan 23, 2009, at 4:34 AM, davinci-linux-open-source-requ...@linux.davincidsp.com wrote: DM6446 MUSB ___ 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 MUSB
Hello. Brian Rhodes wrote: Is PIO ONLY the only working USB mode in the current GIT kernel? By working, I mean without periodic reset. PIO is suitable for my application, but I just merged the latest GIT code into our kernel tree and without CONFIG_MUSB_PIO_ONLY=y USB does not work very well, so I was curious if I had possibly overlooked something. Does the CPPI DMA mode work well on DM6446 in the current GIT code? I don't think so. In particular, sending data via DMA should cause issues (perhaps indeed ending in reset). Thanks. WBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: omap-L1xxx
Sorry, a typo. It should be "With the directory/file name changes being made ..." Zhengting He (Ph.D) Application Engineer DSP Catalog email: z-...@ti.com voice: 281-274-4355 fax: 281-274-2279 -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of He, Zhengting Sent: 2009年1月22日 16:17 To: Kevin Hilman Cc: davinci-linux-open-source@linux.davincidsp.com; Wells, Kimberly; McGoldrick, Bobby; Venkat, Subbu; Friedland, David Subject: RE: omap-L1xxx Kevin, Thanks a lot for your quick response. I think serious customers will need to go into that level and modify the drivers for their customized boards, special requirement etc. WITH the directory/file name changes being made, it is easy for them to find out where the things are that they need to change. It also brings them little confusion. Addressing it in documentation is also a solution but personally I don't feel that's a solution enough. Given the fact that there are already so many documentations floating around for a complicated device, a user may stay away from the documentation and step into the source directly. Zhengting He (Ph.D) Application Engineer DSP Catalog email: z-...@ti.com voice: 281-274-4355 fax: 281-274-2279 -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: 2009年1月22日 16:05 To: He, Zhengting Cc: Mark A. Greer; Longley, Lester; Wells, Kimberly; McGoldrick, Bobby; Venkat, Subbu; Friedland, David; Nori, Sekhar; davinci-linux-open-source@linux.davincidsp.com Subject: Re: omap-L1xxx "He, Zhengting" writes: > Hi, All, >After some discussion internally in TI, I think we (as TI catalog) would > like to change the proposal a little bit. > > 1. The macros and source code will have da830 only. (no change) > 2. The menuconfig prompts will have "DA830/OMAP-L137" in them. (no change) > 3. The defconfig would be called da830_omapl137_defconfig (no change). So far, so good. > 4. The file and directory names should also have omapl137. (CHANGE) > > I have listed the following directory and file names which are > required to be changed. (There are not many). With the > file/directory name change, OMAPL137 users can tell which code is > specifically applicable to OMAPL137 at a first glance. Does everyone > agree this change? Personally, I think this is a bit cumbersome. I'm perfectly fine with the user-visible names and strings having both, but enforcing this type of naming into the kernel structure itself is overkill IMHO. Do you expect most users to be digging into the kernel at that level? If so, I would rather see this addressed in Documentation that comes with the product rather than having filenames carry the burden. My $0.02. Kevin > /**/ > /* Directory names to be changed */ > /**/ > include/config/mach/da8xx > > include/config/snd/da8xx > > arch/arm/mach-da8xx > > drivers/char/da8xx_lcd > > drivers/video/da8xx > > /**/ > /* File names to be changed */ > /**/ > arch/arm/mach-da8xx/da8xx.h > > include/config/rtc/drv/da8xx.h > > drivers/usb/musb/da8xx.c > > drivers/video/da8xx/da8xx_fb.c > > drivers/video/da8xx/da8xx_fb.h > > drivers/video/da8xx/da8xx_lcdc.h > > > > Zhengting He (Ph.D) > Application Engineer > DSP Catalog > email: z-...@ti.com > voice: 281-274-4355 > fax: 281-274-2279 > > ___ 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: omap-L1xxx
Kevin, Thanks a lot for your quick response. I think serious customers will need to go into that level and modify the drivers for their customized boards, special requirement etc. Without the directory/file name changes being made, it is easy for them to find out where the things are that they need to change. It also brings them little confusion. Addressing it in documentation is also a solution but personally I don't feel that's a solution enough. Given the fact that there are already so many documentations floating around for a complicated device, a user may stay away from the documentation and step into the source directly. Zhengting He (Ph.D) Application Engineer DSP Catalog email: z-...@ti.com voice: 281-274-4355 fax: 281-274-2279 -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: 2009年1月22日 16:05 To: He, Zhengting Cc: Mark A. Greer; Longley, Lester; Wells, Kimberly; McGoldrick, Bobby; Venkat, Subbu; Friedland, David; Nori, Sekhar; davinci-linux-open-source@linux.davincidsp.com Subject: Re: omap-L1xxx "He, Zhengting" writes: > Hi, All, >After some discussion internally in TI, I think we (as TI catalog) would > like to change the proposal a little bit. > > 1. The macros and source code will have da830 only. (no change) > 2. The menuconfig prompts will have "DA830/OMAP-L137" in them. (no change) > 3. The defconfig would be called da830_omapl137_defconfig (no change). So far, so good. > 4. The file and directory names should also have omapl137. (CHANGE) > > I have listed the following directory and file names which are > required to be changed. (There are not many). With the > file/directory name change, OMAPL137 users can tell which code is > specifically applicable to OMAPL137 at a first glance. Does everyone > agree this change? Personally, I think this is a bit cumbersome. I'm perfectly fine with the user-visible names and strings having both, but enforcing this type of naming into the kernel structure itself is overkill IMHO. Do you expect most users to be digging into the kernel at that level? If so, I would rather see this addressed in Documentation that comes with the product rather than having filenames carry the burden. My $0.02. Kevin > /**/ > /* Directory names to be changed */ > /**/ > include/config/mach/da8xx > > include/config/snd/da8xx > > arch/arm/mach-da8xx > > drivers/char/da8xx_lcd > > drivers/video/da8xx > > /**/ > /* File names to be changed */ > /**/ > arch/arm/mach-da8xx/da8xx.h > > include/config/rtc/drv/da8xx.h > > drivers/usb/musb/da8xx.c > > drivers/video/da8xx/da8xx_fb.c > > drivers/video/da8xx/da8xx_fb.h > > drivers/video/da8xx/da8xx_lcdc.h > > > > Zhengting He (Ph.D) > Application Engineer > DSP Catalog > email: z-...@ti.com > voice: 281-274-4355 > fax: 281-274-2279 > > ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: omap-L1xxx
"He, Zhengting" writes: > Hi, All, >After some discussion internally in TI, I think we (as TI catalog) would > like to change the proposal a little bit. > > 1. The macros and source code will have da830 only. (no change) > 2. The menuconfig prompts will have "DA830/OMAP-L137" in them. (no change) > 3. The defconfig would be called da830_omapl137_defconfig (no change). So far, so good. > 4. The file and directory names should also have omapl137. (CHANGE) > > I have listed the following directory and file names which are > required to be changed. (There are not many). With the > file/directory name change, OMAPL137 users can tell which code is > specifically applicable to OMAPL137 at a first glance. Does everyone > agree this change? Personally, I think this is a bit cumbersome. I'm perfectly fine with the user-visible names and strings having both, but enforcing this type of naming into the kernel structure itself is overkill IMHO. Do you expect most users to be digging into the kernel at that level? If so, I would rather see this addressed in Documentation that comes with the product rather than having filenames carry the burden. My $0.02. Kevin > /**/ > /* Directory names to be changed */ > /**/ > include/config/mach/da8xx > > include/config/snd/da8xx > > arch/arm/mach-da8xx > > drivers/char/da8xx_lcd > > drivers/video/da8xx > > /**/ > /* File names to be changed */ > /**/ > arch/arm/mach-da8xx/da8xx.h > > include/config/rtc/drv/da8xx.h > > drivers/usb/musb/da8xx.c > > drivers/video/da8xx/da8xx_fb.c > > drivers/video/da8xx/da8xx_fb.h > > drivers/video/da8xx/da8xx_lcdc.h > > > > Zhengting He (Ph.D) > Application Engineer > DSP Catalog > email: z-...@ti.com > voice: 281-274-4355 > fax: 281-274-2279 > > > > -Original Message- > From: davinci-linux-open-source-boun...@linux.davincidsp.com > [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of > Mark A. Greer > Sent: 2009年1月22日 11:54 > To: Longley, Lester > Cc: davinci-linux-open-source@linux.davincidsp.com; Wells, Kimberly; > McGoldrick, Bobby > Subject: Re: omap-L1xxx > > On Thu, Jan 22, 2009 at 09:53:43AM -0600, Longley, Lester wrote: >> Hi Mark, >> >> From: Mark A. Greer [mailto:mgr...@mvista.com] >> > On Wed, Jan 21, 2009 at 11:35:07AM -0800, Kevin Hilman wrote: >> > > "Longley, Lester" writes: >> > > >> > > [ ... ] >> > > >> > > > From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com] >> > > >> > > [ ... ] >> > > >> > > >> So, how should we reference to OMAP-L1x in kernel (in order to >> > > >> avoid the >> > > >> confusion with real OMAP)? >> > > > >> > > > It's the strong preference from my group, Performance Media, that >> > > > "da830" be *included* in the name. >> > > >> > > Lester, thanks for sharing the views of your group. >> > > >> > > Do you mean included along with the omapl1x name? Or would your team >> > > be OK with only the da830 naming (which would be my preference)? >> > > >> > > For in-kernel code, I think it would be *really* clumsy to have both. >> > > In other words, I would much rather have >> > > >> > > #define DA830_MY_VAR >> > > void da830_my_func(void); >> > > >> > > OR >> > > >> > > #define OMAPL1X_MY_VAR >> > > void omapl1x_my_func(void); >> > > >> > > instead of: >> > > >> > > #define DA830_OMAPL1X_MY_VAR >> > > void da830_omapl1x_my_func(void); >> > > >> > > Which I think would be more confusing than informative. >> > > >> > > > Maybe one could consider that a side benefit of such naming is >> > > > easier distinction versus "real OMAP" (or maybe "original OMAP"). >> > > >> > > Yes, I think that using the d830 naming only would avoid this >> > > confusion. >> > > >> > > > Moreover, many users of the chip will utilize the DSP-side audio >> > > > code available for DA830, and so helping them readily identify the >> > > > appropriate kernel is important to them & to us. This need can >> > > > hopefully be addressed by inclusion of "da830_" prefix in the kernel >> > > > name. >> > > >> > > Will these users have much visibility into the in-kernel naming? Or >> > > are you primarily concerned with the naming of how the kernel as it is >> > > packaged and visible to non kernel-developers. >> > >> > To try to get closure, here is a proposal: >> > >> > File names/macros/config options will have da830 only but the menuconfig >> > prompts will have "DA830/OMAP-L137" in them. The defconfig would be >> > called da8xx_omapl137_defconfig. >> > >> > Everyone agree? >> >> Did you mean "da830_omapl137_defconfig", rather than >> "da8xx_omapl137_defconfig"? > > Oops, yes, that's what I meant. Sorry... > > Ma
RE: omap-L1xxx
Hi, All, After some discussion internally in TI, I think we (as TI catalog) would like to change the proposal a little bit. 1. The macros and source code will have da830 only. (no change) 2. The menuconfig prompts will have "DA830/OMAP-L137" in them. (no change) 3. The defconfig would be called da830_omapl137_defconfig (no change). 4. The file and directory names should also have omapl137. (CHANGE) I have listed the following directory and file names which are required to be changed. (There are not many). With the file/directory name change, OMAPL137 users can tell which code is specifically applicable to OMAPL137 at a first glance. Does everyone agree this change? /**/ /* Directory names to be changed */ /**/ include/config/mach/da8xx include/config/snd/da8xx arch/arm/mach-da8xx drivers/char/da8xx_lcd drivers/video/da8xx /**/ /* File names to be changed */ /**/ arch/arm/mach-da8xx/da8xx.h include/config/rtc/drv/da8xx.h drivers/usb/musb/da8xx.c drivers/video/da8xx/da8xx_fb.c drivers/video/da8xx/da8xx_fb.h drivers/video/da8xx/da8xx_lcdc.h Zhengting He (Ph.D) Application Engineer DSP Catalog email: z-...@ti.com voice: 281-274-4355 fax: 281-274-2279 -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Mark A. Greer Sent: 2009年1月22日 11:54 To: Longley, Lester Cc: davinci-linux-open-source@linux.davincidsp.com; Wells, Kimberly; McGoldrick, Bobby Subject: Re: omap-L1xxx On Thu, Jan 22, 2009 at 09:53:43AM -0600, Longley, Lester wrote: > Hi Mark, > > From: Mark A. Greer [mailto:mgr...@mvista.com] > > On Wed, Jan 21, 2009 at 11:35:07AM -0800, Kevin Hilman wrote: > > > "Longley, Lester" writes: > > > > > > [ ... ] > > > > > > > From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com] > > > > > > [ ... ] > > > > > > >> So, how should we reference to OMAP-L1x in kernel (in order to > > > >> avoid the > > > >> confusion with real OMAP)? > > > > > > > > It's the strong preference from my group, Performance Media, that > > > > "da830" be *included* in the name. > > > > > > Lester, thanks for sharing the views of your group. > > > > > > Do you mean included along with the omapl1x name? Or would your team > > > be OK with only the da830 naming (which would be my preference)? > > > > > > For in-kernel code, I think it would be *really* clumsy to have both. > > > In other words, I would much rather have > > > > > > #define DA830_MY_VAR > > > void da830_my_func(void); > > > > > > OR > > > > > > #define OMAPL1X_MY_VAR > > > void omapl1x_my_func(void); > > > > > > instead of: > > > > > > #define DA830_OMAPL1X_MY_VAR > > > void da830_omapl1x_my_func(void); > > > > > > Which I think would be more confusing than informative. > > > > > > > Maybe one could consider that a side benefit of such naming is > > > > easier distinction versus "real OMAP" (or maybe "original OMAP"). > > > > > > Yes, I think that using the d830 naming only would avoid this > > > confusion. > > > > > > > Moreover, many users of the chip will utilize the DSP-side audio > > > > code available for DA830, and so helping them readily identify the > > > > appropriate kernel is important to them & to us. This need can > > > > hopefully be addressed by inclusion of "da830_" prefix in the kernel > > > > name. > > > > > > Will these users have much visibility into the in-kernel naming? Or > > > are you primarily concerned with the naming of how the kernel as it is > > > packaged and visible to non kernel-developers. > > > > To try to get closure, here is a proposal: > > > > File names/macros/config options will have da830 only but the menuconfig > > prompts will have "DA830/OMAP-L137" in them. The defconfig would be > > called da8xx_omapl137_defconfig. > > > > Everyone agree? > > Did you mean "da830_omapl137_defconfig", rather than > "da8xx_omapl137_defconfig"? Oops, yes, that's what I meant. Sorry... Mark -- ___ 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: omap-L1xxx
"Mark A. Greer" writes: > On Tue, Jan 20, 2009 at 05:26:38PM -0800, Kevin Hilman wrote: >> "Mark A. Greer" writes: >> >> > On Tuesday 20 January 2009, David Brownell wrote: >> > >> > Hi David & Kevin. >> > >> > [My apologies for being out of the loop on this. I just subscribed a >> > few mins ago and still catching up on the emails.] >> >> Hi Mark, > > Hi Kevin. > >> I was hoping you would be joining this thread... :) >> > >> > Regarding the name >> > -- >> > >> > I really don't like the omap creep that's happening. The da830 is >> > based on davinci and not at all on an omap so I'd like to keep it >> > contained as possible. TI has expressed a strong desire to have >> > both so our current plan is the rename the defconfig >> > to "da830_omapl137_defconfig" and menuconfig text options to say >> > "DA830/OMAP-L137...". I don't know if this will be acceptable to the >> > community. >> >> I don't care much about the defconfig names or the Kconfig option >> names. The bigger question is what to to use as function/#define >> prefixes (current code uses DM646X_* DM355_*, DM644X_* etc.. I think >> using both will result in long names for not very much gain. > > Agreed. > >> Personally, if TI is OK with it, for kernel-internal names, I would >> lean towards the da8xx prefix rather thant the omap prefix since it >> would result in less confusion with the omap names. > > Unless something changes, the .config options and macros will still be > DA8XX so I think [hope] we're okay. > >> > Regarding the code split >> > >> > >> > I agree, I don't think there has been a convincing argument yet. >> > I'll try to make one... >> > >> > First some background. We originally put the da8xx code (what we've >> > called it but da830 may be a better name) in mach-davinci. We fought >> > with that for quite some time but all the #ifdef's and other ugly >> > things continued to add up as we learned more nits about the hardware >> > that made it more & more different than a true davinci. So, we ended >> > up splitting the code. >> > >> > The biggest drivers for splitting the code (that I remember ATM) were: >> > >> > 1) Reduce the amount of #ifdef-ery and other ugliness; however we didn't >> >split include/asm-arm/arch-davinci (but neither did omap). >> >> If done right, support for multiple devices should need very minimal >> #ifdefs, if any. As patches have come to me with device or board >> support added with ifdefs they are always NAK'd. The right way is to >> use cpu_is_* or machine_is_* macros along with __init data and >> functions. > > Right, and that what's we did and have been calling "splitting"/"refactoring" > the code. Basicaly, where #ifdef's would have had to go, the code was > refactored and the correct value passed into the routine instead of > using the previous macro or whatever. OK, good. > Actually, you're supporting one of my points. That is, no matter > whether the code is kept in one dir or spread over three dirs, the code > will be split/refactored/. Its just a > technical necessity. We _will_ end up with 3 sets of code, a > davinci-specific set, a da8xx-specific set, and a common set. For cases where da8xx and davinci are completely different, I completely agree. > The real question is whether all three sets go in one dir or each > set gets its own dir. Well, that's one question, but that's not the real question for me. The real question for me is which da8xx IP blocks are really that different from the davinci family to warrant a new file. From what I have seen so far in the modules I have looked at, the da8xx IP blocks (at least ones that would handled by mach-* code) are either the same, or extension of existing davinci HW IP. The only exception being the new CP_INTC, and maybe the new mux, but I haven't looked at the details there yet. IOW, rather than add new files for da8xx, I would rather see the existing davinci files refactored (maybe generalized is a better term) with support for the da8xx added to the same file. Maybe you guys have already done it this way. I have no idea since I don't have access to the da8xx kernel code. [hint, hint...] I think it would be very helpful for me to look at how you've refactored the code already. Which parts you extended, which parts you separated into new files etc. >> > 2) Remove unnecessary bloat from davinci code & data laying around >> > but entirely useless to us. >> >> Again, when done right the bloat can be mostly handled with __init >> data and functions. And for production, simply compile only with the >> device/board you care about. > > Actually, almost all of that statically initialized data is not __initdata > and can't be (e.g., 'stuct clk' data, 'struct resource' data, platform_data). > > Its not megabytes but it is a waste. > >> > Some more notes: >> > >> > - We (or at least *I*) had no desire to have the same kernel binary >> > run on both a da8xx and a davinci. So,
DM6446 MUSB
Hello, Is PIO ONLY the only working USB mode in the current GIT kernel? By working, I mean without periodic reset. PIO is suitable for my application, but I just merged the latest GIT code into our kernel tree and without CONFIG_MUSB_PIO_ONLY=y USB does not work very well, so I was curious if I had possibly overlooked something. Does the CPPI DMA mode work well on DM6446 in the current GIT code? musb_hdrc: version 6.0, pio, host, debug=0 musb_hdrc: ConfigData=0x06 (UTMI-8, dyn FIFOs, SoftConn) musb_hdrc: MHDRC RTL version 1.300 musb_hdrc: setup fifo_mode 2 musb_hdrc: 7/9 max ep, 2624/4096 memory musb_hdrc: hw_ep 0shared, max 64 musb_hdrc: hw_ep 1tx, max 512 musb_hdrc: hw_ep 1rx, max 512 musb_hdrc: hw_ep 2tx, max 512 musb_hdrc: hw_ep 2rx, max 512 musb_hdrc: hw_ep 3shared, max 256 musb_hdrc: hw_ep 4shared, max 256 musb_hdrc: USB Host mode controller at c800 using PIO, IRQ 12 musb_hdrc musb_hdrc: MUSB HDRC host driver musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1 Thanks. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: emdebian and Ubuntu?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philip Balister wrote: > Yusuf Caglar AKYUZ wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Hi, >> >> Recently openembedded folks published an online image builder at [1] for >> various targets including davinci-dvevm. In case you're interested in a >> new fs image... > > If you use this this, please let us I know how it works for you. I can > make sure any emails on this list get to the right people. > > Thanks, > I don't think that I'm going to use this one, because I'm using OE for most of my development cycle already. OTH, I can say that this type of ready/to/use/customizable fs image tool is invaluable for anyone. I wouldn't be learning openembedded if this was published some months ago :) And some comments about general OE/Angstrom-DVEVM experience: 1) Highly customizable fs and tools for DaVinci, in a very easy way. 2) Support for dsplink and cmem modules for the DSP side. Given that building and running dsplink for latest kernels is virtually impossible for average user, this is life-saving . 3) Last but not the least, powerful staging environment for development. If you happen to compile/build many different 3rd applications, you have all the libraries, sources, etc. at your hand. Thanks for this great job. Best regards, Caglar > Philip > > > > > ___ > Davinci-linux-open-source mailing list > Davinci-linux-open-source@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkl4sx8ACgkQ/nL+S5dojegPAgCaAixqaDhzN7lsd94ccr/cZ64a 19sAniQp32+Ww5SjFTncShrjqOiQAQQj =aq6w -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: omap-L1xxx
On Thu, Jan 22, 2009 at 09:53:43AM -0600, Longley, Lester wrote: > Hi Mark, > > From: Mark A. Greer [mailto:mgr...@mvista.com] > > On Wed, Jan 21, 2009 at 11:35:07AM -0800, Kevin Hilman wrote: > > > "Longley, Lester" writes: > > > > > > [ ... ] > > > > > > > From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com] > > > > > > [ ... ] > > > > > > >> So, how should we reference to OMAP-L1x in kernel (in order to > > > >> avoid the > > > >> confusion with real OMAP)? > > > > > > > > It's the strong preference from my group, Performance Media, that > > > > "da830" be *included* in the name. > > > > > > Lester, thanks for sharing the views of your group. > > > > > > Do you mean included along with the omapl1x name? Or would your team > > > be OK with only the da830 naming (which would be my preference)? > > > > > > For in-kernel code, I think it would be *really* clumsy to have both. > > > In other words, I would much rather have > > > > > > #define DA830_MY_VAR > > > void da830_my_func(void); > > > > > > OR > > > > > > #define OMAPL1X_MY_VAR > > > void omapl1x_my_func(void); > > > > > > instead of: > > > > > > #define DA830_OMAPL1X_MY_VAR > > > void da830_omapl1x_my_func(void); > > > > > > Which I think would be more confusing than informative. > > > > > > > Maybe one could consider that a side benefit of such naming is > > > > easier distinction versus "real OMAP" (or maybe "original OMAP"). > > > > > > Yes, I think that using the d830 naming only would avoid this > > > confusion. > > > > > > > Moreover, many users of the chip will utilize the DSP-side audio > > > > code available for DA830, and so helping them readily identify the > > > > appropriate kernel is important to them & to us. This need can > > > > hopefully be addressed by inclusion of "da830_" prefix in the kernel > > > > name. > > > > > > Will these users have much visibility into the in-kernel naming? Or > > > are you primarily concerned with the naming of how the kernel as it is > > > packaged and visible to non kernel-developers. > > > > To try to get closure, here is a proposal: > > > > File names/macros/config options will have da830 only but the menuconfig > > prompts will have "DA830/OMAP-L137" in them. The defconfig would be > > called da8xx_omapl137_defconfig. > > > > Everyone agree? > > Did you mean "da830_omapl137_defconfig", rather than > "da8xx_omapl137_defconfig"? Oops, yes, that's what I meant. Sorry... 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: omap-L1xxx
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sergei Shtylyov wrote: > Hello. > Hello, >Besides, how are you using DaVinci? Asking because OMAP-L1xx/ and > DA8xx both seem to be targeted to the different market niches than > DaVinci -- at least the former completely lack the video support that > the later offered... > Video applications, industrial control(mainly HMI) and data acquisition. SOC can be 6446, 355 or 335 depending on the cost/performance criteria. I agree that these are not primary areas for OMAP-L1xx but I'm sure it will be offered to many portable applications. Besides, it's unique in one way compared to DaVincis, a floating point dsp which offers developers more flexible programming. I'll not be surprised if many people prefer OMAP-L1xx to DaVinci with these compatible price levels. Best regards, Caglar -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkl4rh4ACgkQ/nL+S5dojegDFQCeKD/16FQkAZWsACCIJJZOVqzj 32QAoKvQ2J79knrgT93Fh5SX0EHJO/zs =6in4 -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: omap-L1xxx
Hello. Yusuf Caglar AKYUZ wrote: Absolutely. Here's an example of enforcing your private opinion... Yes, this is my private opinion, but I am not enforcing anything. I am attempting to share the technical arguments behind my private opinion so folks know where I'm coming from. As the person who has to maintain a single code base that will run on all these platforms, I have a *very* strong desire to have a single binary run across multiple SoCs. May be sholld also ask tbe opinion of TI and the real users? I am very eager to hear more opinions. That's what this list is all about. We have some DaVinci based boards here, using single kernel for all is quite time-and-effort saver for us. It would be really nice to be able to boot the same kernel(s) in later designs as well, given that the arch is similar. Besides, how are you using DaVinci? Asking because OMAP-L1xx/ and DA8xx both seem to be targeted to the different market niches than DaVinci -- at least the former completely lack the video support that the later offered... Best regards, Caglar WBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: emdebian and Ubuntu?
Yusuf Caglar AKYUZ wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrea Gasparini wrote: Ben West spiffera, alle Wednesday 21 January 2009 circa: However, the decision by Ubuntu maintainers above now means I must set up parallel Debian system. Has anyone else encountered this problem with Ubuntu and emdebian? Uhm. I never tried, but can't you simply install the Debian package? ( I mean, downloaded from _debian_ repository, not ubuntu one ) Usually, with some little hacks, there's no need to have various Ubuntu/Debian systems running. Anyway, I think you'll ear about me , as I'd like to give emdebian a try, and kick out MV filesystems. Bye Hi, Recently openembedded folks published an online image builder at [1] for various targets including davinci-dvevm. In case you're interested in a new fs image... If you use this this, please let us I know how it works for you. I can make sure any emails on this list get to the right people. Thanks, Philip smime.p7s Description: S/MIME Cryptographic 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: Resizer Initialization
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Steve Ressler wrote:
> Hi,
>
>>Are you sure that resizer takes major number 254? I guess it uses
>>dynamic number allocation.
>
>
> I believe you are correct, it uses dynamic number allocation. 254 was the
> number
> I saw it using when the device file was created by the init scripts. How can
> I
> find the correct major number? I'm not running the init scripts, so there is
> nothing in /proc to check.
>
> Maybe I should have asked: How can I use the resizer without running the init
> scripts?
>
AFAIK, you cannot check device numbers without proc or sysfs. Some
options coming to mind:
1)
Edit resizer driver drivers/char/davinci_resizer.c Change line:
result = alloc_chrdev_region(&dev, ZERO, 1, DRIVER_NAME);
to:
dev = MKDEV(254_or_some_number_unique_in_the_system, ZERO);
result = register_chrdev_region(dev, 1, DRIVER_NAME);
Don't forget to create node for the number you choose as major.
2)
Create a file in your filesystem and edit, let's say /home/my_init.sh:
#!/bin/sh
mount /proc
RES=$(cat /proc/devices | awk '/davinci_resizer/ {print $1}')
rm -f /dev/resizer
mknod /dev/resizer c $RES 0
/path/to/your/app/app
Then start this script as init, instead of your application.
3)
You can also edit your inittab. Instead of running init scripts you can
just mount some filesystems and then start your application.
I don't use MV fs and kernel, so I can't try these. But I guess they may
give some ideas.
Regards,
Caglar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iEYEARECAAYFAkl4mH4ACgkQ/nL+S5dojeht1QCfVRqG0HxB7zqUIs6c2l4QRhrC
/3YAoJb573wRtHKDi0ArFEqk83wrOKI5
=3nas
-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: omap-L1xxx
Hi Mark, From: Mark A. Greer [mailto:mgr...@mvista.com] > On Wed, Jan 21, 2009 at 11:35:07AM -0800, Kevin Hilman wrote: > > "Longley, Lester" writes: > > > > [ ... ] > > > > > From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com] > > > > [ ... ] > > > > >> So, how should we reference to OMAP-L1x in kernel (in order to avoid > > >> the > > >> confusion with real OMAP)? > > > > > > It's the strong preference from my group, Performance Media, that > > > "da830" be *included* in the name. > > > > Lester, thanks for sharing the views of your group. > > > > Do you mean included along with the omapl1x name? Or would your team > > be OK with only the da830 naming (which would be my preference)? > > > > For in-kernel code, I think it would be *really* clumsy to have both. > > In other words, I would much rather have > > > > #define DA830_MY_VAR > > void da830_my_func(void); > > > > OR > > > > #define OMAPL1X_MY_VAR > > void omapl1x_my_func(void); > > > > instead of: > > > > #define DA830_OMAPL1X_MY_VAR > > void da830_omapl1x_my_func(void); > > > > Which I think would be more confusing than informative. > > > > > Maybe one could consider that a side benefit of such naming is > > > easier distinction versus "real OMAP" (or maybe "original OMAP"). > > > > Yes, I think that using the d830 naming only would avoid this > > confusion. > > > > > Moreover, many users of the chip will utilize the DSP-side audio > > > code available for DA830, and so helping them readily identify the > > > appropriate kernel is important to them & to us. This need can > > > hopefully be addressed by inclusion of "da830_" prefix in the kernel > > > name. > > > > Will these users have much visibility into the in-kernel naming? Or > > are you primarily concerned with the naming of how the kernel as it is > > packaged and visible to non kernel-developers. > > To try to get closure, here is a proposal: > > File names/macros/config options will have da830 only but the menuconfig > prompts will have "DA830/OMAP-L137" in them. The defconfig would be > called da8xx_omapl137_defconfig. > > Everyone agree? Did you mean "da830_omapl137_defconfig", rather than "da8xx_omapl137_defconfig"? -Lester ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: omap-L1xxx
On Wed, Jan 21, 2009 at 11:35:07AM -0800, Kevin Hilman wrote: > "Longley, Lester" writes: > > [ ... ] > > > From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com] > > [ ... ] > > >> So, how should we reference to OMAP-L1x in kernel (in order to avoid > >> the > >> confusion with real OMAP)? > > > > It's the strong preference from my group, Performance Media, that > > "da830" be *included* in the name. > > Lester, thanks for sharing the views of your group. > > Do you mean included along with the omapl1x name? Or would your team > be OK with only the da830 naming (which would be my preference)? > > For in-kernel code, I think it would be *really* clumsy to have both. > In other words, I would much rather have > > #define DA830_MY_VAR > void da830_my_func(void); > > OR > > #define OMAPL1X_MY_VAR > void omapl1x_my_func(void); > > instead of: > > #define DA830_OMAPL1X_MY_VAR > void da830_omapl1x_my_func(void); > > Which I think would be more confusing than informative. > > > Maybe one could consider that a side benefit of such naming is > > easier distinction versus "real OMAP" (or maybe "original OMAP"). > > Yes, I think that using the d830 naming only would avoid this > confusion. > > > Moreover, many users of the chip will utilize the DSP-side audio > > code available for DA830, and so helping them readily identify the > > appropriate kernel is important to them & to us. This need can > > hopefully be addressed by inclusion of "da830_" prefix in the kernel > > name. > > Will these users have much visibility into the in-kernel naming? Or > are you primarily concerned with the naming of how the kernel as it is > packaged and visible to non kernel-developers. To try to get closure, here is a proposal: File names/macros/config options will have da830 only but the menuconfig prompts will have "DA830/OMAP-L137" in them. The defconfig would be called da8xx_omapl137_defconfig. Everyone agree? 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: Resizer Initialization
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve Ressler wrote: > Hello, > > I'd like to use the resizer in my application and quick boot time is also > very > important to me. In order to reduce boot time, I am bypassing the init > scripts > with init=/bin/bash in the bootargs. When I bypass the scripts, I dont get a > device file in /dev for the resizer. I've tried creating it myself with > "mknod > /dev/davinci_resizer c 254 0" but the resizer doesn't seem to work. Is there > something I am missing? > Are you sure that resizer takes major number 254? I guess it uses dynamic number allocation. Caglar > Is it possible to use the resizer without running all the init scripts? > Why not? > Thanks, > Steve > > > > > ___ > Davinci-linux-open-source mailing list > Davinci-linux-open-source@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkl4m7wACgkQ/nL+S5dojeiVdQCgn2Zd428ADkY0Lgf2uqxSB110 nz8AnjPY+5B+lRV+vjXBE/pmJtbP/7wV =aVLU -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
Resizer Initialization
Hello, I'd like to use the resizer in my application and quick boot time is also very important to me. In order to reduce boot time, I am bypassing the init scripts with init=/bin/bash in the bootargs. When I bypass the scripts, I dont get a device file in /dev for the resizer. I've tried creating it myself with "mknod /dev/davinci_resizer c 254 0" but the resizer doesn't seem to work. Is there something I am missing? Is it possible to use the resizer without running all the init scripts? Thanks, 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: omap-L1xxx
Hello. Kevin Hilman wrote: From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com] [ ... ] So, how should we reference to OMAP-L1x in kernel (in order to avoid the confusion with real OMAP)? It's the strong preference from my group, Performance Media, that "da830" be *included* in the name. Lester, thanks for sharing the views of your group. [...] Maybe one could consider that a side benefit of such naming is easier distinction versus "real OMAP" (or maybe "original OMAP"). Yes, I think that using the d830 naming only would avoid this confusion. That's all good but what about the coming RMS320DA828? Won't we have to rename everything very soon? Kevin WBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: omap-L1xxx
Hello. David Brownell wrote: We didn't want to cause two separate packages (DA830 & OMAP-L137) to be created, but yet we want both to have some top-level visibility. To clarify: DA830 "Aureus" (new brand) and Note that there's also DA828 coming RSN: http://focus.ti.com/apps/docs/gencontent.tsp?contentId=52390&appId=1 WBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Problem booting with different tftp and dhcp server
Jon Povey wrote: I am trying to boot via TFTP using NFS file system. My tftp server is my laptop and the dhcp server is my company server. My problem is that uboot tries to tftp from the dhcp server and not from the server that I specified with serverip. Is this a known issue? Is there any work-around? Hi, I had the same issue. You can either change your DHCP server settings to supply the right TFTP server IP, or use the workaround I did: Set the environment variable "autoload" to "no" - this stops "dhcp" from trying to immediately load from TFTP. In your bootcmd, explicitly reset the environment variable "serverip" after the "dhcp" command which sets it incorrectly. Some of my u-boot environment looks like this: # printenv bootfile=jon/uImage autoload=no bootcmd=dhcp;setenv serverip 192.168.1.234;tftp;bootm It worked! Thanks a lot. Abdel. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Davinci Linux kernel debugger
Ashish, KGDBOS and KGDBOE should both be available on the MV 2.6.10 kernel. I noticed kgdb is in the git tree, but never tried it. Regards, Steve On Thu, 2009-01-22 at 12:31 +, ashish pareek wrote: > Hi , > Which is the easily available davinci's MV linux kernel debugger ? > Any thoughts about KGDB ? > > Pls find me a link to such debugger that supports davinci(ARM 9) . > I am a user of DM355. > > Ashish > > > > > ___ > 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 kernel debugger
Hi , Which is the easily available davinci's MV linux kernel debugger ? Any thoughts about KGDB ? Pls find me a link to such debugger that supports davinci(ARM 9) . I am a user of DM355. Ashish ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Davinci i2c warning : command completely failed
Hi David, We did not find following code snipest in our kernel : psc = 26; /* To get 1MHz clock */ clk = ((i2c_davinci_inputClock/(psc + 1)) / (i2c_davinci_busFreq * 1000)) - 10; If you are having "drivers/busses/i2c-davinci.c" file that is availaable on "http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git " , then please send it to me, so that I can compare that file to my existing file. In fact, we have one git kernel and in that we found the following code. /* get minimum of 7 MHz clock, but max of 12 MHz */ psc = (input_clock / 700) - 1; if ((input_clock / (psc + 1)) > 1200) psc++; /* better to run under spec than over */ d = (psc >= 2) ? 5 : 7 - psc; clk = ((input_clock / (psc + 1)) / (pdata->bus_freq * 1000)) - (d << 1); clkh = clk >> 1; clkl = clk - clkh; We tried to use this code in "drivers/busses/i2c-davinci.c". But still we are getting the same error. So as per your knowledge will this be useful and if yes then please guide us to insert this code in our kernel. Regards, Dhaval Lakkad -- _ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. __ ___ 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 booting with different tftp and dhcp server
Jon Povey wrote: >> I am trying to boot via TFTP using NFS file system. My tftp server is my laptop and the dhcp server is my company server. >> >> My problem is that uboot tries to tftp from the dhcp server and not from the server that I specified with serverip. >> >> Is this a known issue? Is there any work-around? > > Hi, I had the same issue. You can either change your DHCP server > settings to supply the right TFTP server IP, This is not an option unfortunately. > or use the workaround I > did: I'll try that. Thanks a lot! Abdel. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
2.6.28 and VPFE Drivers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm trying to make tvp5146 capture interface work in 2.6.28 with DVEVM. There were some build errors related with davinci_vpfe.c, I fixed them. Current situation is that a simple application can open video device, query capabilities and perform some IOCTLs. It can even detect my PAL analog camera. However, capturing/streaming is not working due to some bugs in the driver, and my kernel crashes. I had to make some functional changes in the driver to fix build errors, and I suspect I need to do more. But I'm not sure if I'm on the correct route or not. Am I missing something or video capture interface at the moment is broken with 2.6.28? [1] Thanks, Caglar -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkl4VcwACgkQ/nL+S5dojejmWQCfW5/CiAdh9ppNUWl+gey5nPe4 8J8An3A5j1d4wcf7/fgMyreOq/Z7qSiP =52Mw -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: emdebian and Ubuntu?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrea Gasparini wrote: > Ben West spiffera, alle Wednesday 21 January 2009 circa: >> However, the decision by Ubuntu maintainers above now means I must set >> up parallel Debian system. >> Has anyone else encountered this problem with Ubuntu and emdebian? > > Uhm. I never tried, but can't you simply install the Debian package? > ( I mean, downloaded from _debian_ repository, not ubuntu one ) > Usually, with some little hacks, there's no need to have various > Ubuntu/Debian systems running. > Anyway, I think you'll ear about me , as I'd like to give emdebian a try, > and kick out MV filesystems. > > Bye Hi, Recently openembedded folks published an online image builder at [1] for various targets including davinci-dvevm. In case you're interested in a new fs image... Regards, Caglar [1] http://amethyst.openembedded.net/~koen/narcissus -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkl4Q6sACgkQ/nL+S5dojegR2wCeIK3t7TftG0YOQi4+eEy0kZAs AIYAn0U3qvjEtZvQZSjq2dcPnD9wvDGm =YGSw -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: emdebian and Ubuntu?
Ben West spiffera, alle Wednesday 21 January 2009 circa: > However, the decision by Ubuntu maintainers above now means I must set > up parallel Debian system. > Has anyone else encountered this problem with Ubuntu and emdebian? Uhm. I never tried, but can't you simply install the Debian package? ( I mean, downloaded from _debian_ repository, not ubuntu one ) Usually, with some little hacks, there's no need to have various Ubuntu/Debian systems running. Anyway, I think you'll ear about me , as I'd like to give emdebian a try, and kick out MV filesystems. Bye -- Andrea Gasparini ImaVis S.r.l. web: www.imavis.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
